Leave a test campaign that accelerates refactoring rather than be exhaustive
This is the 14th post from my sincere dev manifesto series.
I don’t try to increase code or branch coverage. I don’t try to balance the test pyramid. I try to have a harness that allows me to modify code with more confidence more quickly.
I consider a modification as done when it brought its value without increasing risks. When it passed all stages to reach users hands. The quicker I can detect risks increasing, the cheaper I make modifications.
The harness is the main tool helping me accelerate problem detection. The harness goes from compiler indicators to team understanding, and includes code analysis tools, linters, all types of automatic checking, code reviews, coffee machine discussions, testing, letting my mind wander, and more.
The big topic we always wonder about while writing automated checks is granularity.
- A test that only embeds an isolated class runs quickly. But when I need to update the code, if I also need to modify tons of test stubs, I waste time.
- On the other hand, I recently experienced a very smooth refactoring, with confidence, because I had written tests at a higher granularity level than the team was used to.
I only know one heuristic to choose the right granularity level, and I only learned it in 2022: test interfaces you are ready to commit to (talk in French sorry).
Note that you have fewer problems choosing the right granularity level in a functional core corresponding to the right aggregate of the right bounded context: there is only one, side-effect free, functionally relevant, autonomous, quick to run, level of granularity. That looks like an ideal, right? Between that ideal and a spaghetti plate, there is a whole range of code bases, including hexagonal, micro-services, or multi-layered architectures. They all come with their own trade-offs.
One last thing. Feedback speed is the whole test campaign’s job. The team must maintain a consistent campaign. It is one of the many artifacts you need to cherish in a pragmatic way. Please don’t add a automated test for every ticket you implement. Modify the existing campaign so that it tests each aspect of the product in a necessary and sufficient way, and only add tests if it makes sense.
I commit to adapting each test to the level of granularity that looks the most stable to me, and to maintaining a consistent and frugal campaign.
AAAgile 
One comment