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
@barryosull 2021
https://barryosull.com
questions
Using test pain as a design guide (2021)
By Barry O' Sullivan
Using test pain as a design guide (2021)
Automated testing is a necessary part of software development, we need it if we intend to release our software with confidence. The problem is that writing and maintaining tests can be a painful process, especially in legacy code. Tests become brittle and awkward to use over time. What we don't realise is that this pain is telling us how our system should be structured, we just need to listen. In this talk we'll discuss test structure, mocking and system design. We'll then take real testcases and show how we can apply tactical patterns to refactor and express the appropriate design, resulting in an application that is easier to understand and maintain from both a testing and business perspective.
