This article has a new home
Testing has been the focus of Software Quality for a while. It is impossible to make Continuous Delivery without tests. And, if you had ever read the ACCELERATE book, you should know that Continuous Delivery is a key to have a high-performance organization.
There are a lot of articles talking about how to write tests, TDD and what is a testing pyramid. I would like to have a more abstract discussion about what you should to consider before take any decision on tests. After helping few teams to design their test strategy I figure out that there are four principles that helps teams to stay in track on their testing strategy and help them to write better tests. They are pretty simple to remember by the W.O.R.D. acronym.
The Four principles: W.O.R.D.
- It Works
- It Orients the development and code design.
- It is easy to Refactor.
- It is a Debugging tool
It WORKS!
One of the biggest concerns in software quality is to deliver code that works without side effects. Any testing strategy must provide safety so that a made change that passes all tests can be ship to production without fear. A testing strategy that covers the application into different levels is required to reach this level of confidence.
It also requires a team that fully understands that software quality is a role of all.
Developers should not write tests to reach a quality gate metric. They must understand that it will prevent defects and help others understand what that particular piece of code does.
It ORIENTS the development and code design!
A good testing strategy must facilitate the development process since you should be able to test small chunks of a complex solution individually.
Tests give small tips to developers about their code. Tests too complex to read where there is no way to simplify them must be faced as an application code smell.
Of course, TDD plays an important role in this principle since it “is meant to eliminate fear in application development” — Kent Beck.
It is easy to REFACTOR!
I often talk to people about testing, and they usually complain about how sometimes tests make their life miserable during the refactoring process. Tests are not supposed to break during a refactor. It is a smell that your tests are not focusing on at the crucial point of any application: Its behavior.
Sometimes developers focus too much on implementations details. The more implementation details your tests test, the more pain you will face refactoring. Take it easy on mocks and make sure you are validating the application’s behavior rather than a method call.
It is a DEBUGGING tool
There is no application bulletproof, bugs will happen, and when they happen, your testing strategy must be able to simulate these issues. If you cannot simulate a bug, it means that there are few scenarios your test strategy can’t cover, and it directly impacts the “It Works” principle.
Make sure your testing strategy evolves within your application’s complexity.
With these four principles, the rule is to re-iterate! Discuss with your team about your team testing strategy. Check what of them has been tossed aside and how you all can improve to make a better test strategy. I hope these four simple principles will help you to make better and conscious decisions.
