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

  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

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.

  • 556