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



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








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







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

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

lets get to the real stuff

@barryosull 2021


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.

  • 241