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

  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

https://barryosull.com

questions

Using test pain as a design guide

By Barry O' Sullivan

Using test pain as a design guide

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.

  • 125