Using test pain as a design guide

@barryosull 2021

Talk StruCture

Introduction to test pain

Types of pain & what they're telling you

Live examples of painful test code

Questions

What is TEST PAIN

We just need to listen

pain is feedback

common pain points

Can't read the test code

Excessive expects calls

Seeding DB data everywhere

Magic injection of objects and data

Dependency bootstrapping

chains

Have to use

partial mocks

What the pain is telling you (1)

1. Can't read the test code:

Test code is noisy, too many details, need to refactor

2. Seeding DB data is slowing us down:

DB is tightly coupled to your application/domain

3. Dependency bootstrapping everywhere:

Missing encapsulation boundaries (factories)

4. Magic injection of objects and data:

System not written to be testable, needs DI

5. Have to use partial mocks:

Behaviour and infrastructure are muddled together

6. Excessive expects calls:

Behaviour and side-effects are interwoven

What the pain is telling you (2)

Identity & classify

make the pain visible

ESSENTIAL

ACCIDENTAL

OR

SIGNAL

NOISE

OR

the first step

Your inStruments

1. Automatic refactoring tools:

Rename variable/method, extract method/class

2. Naming and being explicit:
Bring clarity by naming and grouping concepts

3. Separation of concerns & encapsulation:
Separate what you're doing from how you're doing it

4. Given/When/Then:

Make it clear, remove noise and confusing details

Code examples

Cleaning up complicated test code to gain clarity
DB seeding pain leading to separation of concerns
Partial mocks that hide concepts

lets get to the real stuff