Using test pain as a design guide
@barryosull 2022
Talk StruCture
Introduction to test pain
Types of pain & what they're telling you
Live refactoring of painful test code
Questions
Prerequisites
Automated testing
DDD tactical patterns
Basic refactoring
Ports and Adapters
What is TEST PAIN
pain is feedback
common pain points
Illegibility
Excessive expects calls
Seeding DB data everywhere
Magic injection of objects and data
Chains of
mocks
Partial mocks
What the pain is telling you (1)
Can't read the test code:
Seeding DB data everywhere:
Chains of mocks:
Too many details; refactor & encapsulate
DB is tightly coupled to your application(s)/domain(s)
Missing encapsulation boundaries
Magic injection of objects and data:
Have to use partial mocks:
Excessive expects calls:
What the pain is telling you (2)
System not written to be testable, needs DI
Behaviour & awkward details are muddled together
Behaviour and side-effects are interwoven
make the pain visible
the first step
refactor your tests
Your inStruments
Naming and explicitness:
Bring clarity by naming and grouping concepts
Given/When/Then:
Make it clear, remove noise and confusing details
Separation of concerns & encapsulation:
Separate what you're doing from how you're doing it
Automatic refactoring tools:
Rename variable/method, extract method/class
Secret weapon
sleep on it
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
Cleaning up complicated test code to gain clarity
Setup/Dependency factories
Testcases
Given/Expectations/When
Verifications
Data Factories
What is this telling us?
Solution: Dependency Injections via Constructor
Pain: Magic injection
Solution: Repositories
Pain: DB Seeding
Solution: ValueObjects
& HTTP Adapter
Pain: Validation & Primitives
+
DB Seeding pain leading to separation of concerns
Event
Repostiory
Event
Broadcaster/
Listener
What the Test is Telling Us
Message Service
+
+
+
Unexpressed concepts
Event & Event Listener
VerificationCodeRepository Test & Code
MessageService Test
MessageService
Partial mocks
that hide concepts
ValueObjects
Ports & Adapters
What the Test is Telling Us
<<interface>>
Request
Requestor
CreateRequest
UpdateRequest
Request & Requestor
HttpClient
UpdateRequestTest
UpdateRequest
Using test pain as a design guide
refactor
your tests
@barryosull 2022
Thank you
Using test pain as a design guide: DDD EU 2022
By Barry O' Sullivan
Using test pain as a design guide: DDD EU 2022
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.
