Modern Test Pyramid - Unit Level
When tests are slow, the feedback to developers is slow, and the cost of rework is high. How can we get faster feedback?
Welcome to the premium edition of Optivem Journal. I write about Modern Test Pyramid & Modern TDD practices to help you escape the nightmare of Legacy Code. I know you're stressed & don’t have time, and you don’t want to wait for several years. If you want support on your TDD journey, join our paid community of 170+ senior engineers & engineering leaders - you’ll get instant access to group chat & live Q&As:
Component Level Testing provides effective Developer Facing feedback.
Component Level Testing is very useful for developers, because it provides the following:
Commit Developer Feedback: Developers don’t have to wait for the slow-running Acceptance Tests (potentially, 1hr waiting time) to get feedback whether they introduced a regression bug. With Component Level Testing, the developer can get feedback within minutes whether they broke anything with their commit.
Isolated Component Developer Feedback: Developers can get feedback whether their Component works in isolation from other Components and in isolation from External Systems. This means when we see we broke our Component, we can fix it ourselves, don’t need to bother other teams.
The Frontend Developer can get feedback whether the Frontend works correctly in isolation (and whether it can communicate with the Backend), without actually spinning up the Backend.
The Backend Developer can get feedback whether the Backend works in isolation (and whether it can communicate with External Systems), without actually connecting to the External Systems.
In case of Microservice Backend, the Developer can get feedback whether their Microservice works in isolation (and whether it can communicate with other Microservices), without actually spinning up the other Microservices.
But is this Developer Feedback fast enough?
Whilst Component Level testing is necessary & useful, it has some limitations with the feedback loop:
Feedback is not fast enough: Component Tests are slow because they span I/O (e.g., a Backend Component Test involves I/O - hitting the Backend REST API, running with real DB in Testcontainers, running with WireMock/Pact to stub out external HTTP services). The more tests there are, the more problematic this becomes. It is challenging when there is high business logic complexity, which can result in a large number of test cases, making the I/O slowness problem even more noticeable. This increased waiting time is a waste, it discourages us from running tests often, reduces commit frequency. With decreased frequency of test execution, we may accumulate more regression bugs, and have to spend more time debugging.
Feedback is not isolated enough: Component Tests span Presentation Logic, Business Logic, and Infrastructure Logic, so when those tests fail, we have to isolate whether the problem lies in Business Logic or Presentation/Infrastructure Logic. We don’t know, we have to debug.
📢 My next Live Q&A Session about TDD & Unit Tests is on Wed 18th Jun 17:00.
If you’re a Paid Member, you’ll receive 100% discount (see Event Description for instructions). If you’re a Free Member, you can upgrade now:
Solution: Unit Level Testing
How can we get fast feedback for Business Logic, so that even if we have thousands of test cases, that we can get feedback within milliseconds/seconds and not have to wait several minutes? In this way, we minimize waiting time for developers. By reducing the waiting time, developers will be incentivized to run tests more often, thus commit more often. This enables developers to discover Regression Bugs ASAP, which then reduces the amount of time needed to fix the bug (since the change is still fresh in their mind). All this, combined, reduces total development time.
The Solution is:
Unit Tests - testing Business Logic in isolation
Narrow Integration Tests - testing Presentation Logic & Infrastructure Logic in isolation
For a system with Frontend & Monolithic Backend, we choose (separately) for Frontend and Backend whether we stay at just the Component Level or move down to the Unit Level. In the following example, we’ve chosen to stay at the Component Level for Frontend and decided to move to the Unit Level for Backend:
For a system with Frontend & Microservice Backend, we choose (separately) for the Frontend and each Microservice, whether we stay at the Component Level or go down to the Unit Level. In the following example, we’ve chosen to stay at the Component Level for Frontend; for microservices, for some we’ve chosen to stay at the Component Level, and for some we decided to go down to the Unit Level:
