Once we’ve started to unit test, we concentrate on the next piece of code we want to tests. While tactically it maybe the right thing to do, we should think as unit testing as part of whole strategy in testing the feature, and approach in a more structured way.
There are a series of questions we need to answer before and during the development, and even after we’re finished. The method takes into account both TDD and test-after, and specifically works well for legacy systems. It’s a holistic approach to where the tests fit into the development environment and how the code is developed.
The process starts with how we understand the problem and the design, thinking about which tests we need, existing and introduced testability, dealing with design constraints, identifying dependencies and more. Writing tests becomes a small (but still important) part of the process, and it doesn’t end there.
Deciding to write tests for our code is a great big step. Let’s take it a step further and actually think about how to do it.
You can download Gil’s slides here:
Read the talk: