You don’t have a test suite to rely on. I’ve seen and experienced this situation myself before. 

When that happens, altering even the smallest software piece can become a real odyssey. And naturally, that often ends up dramatically causing fear of change, a deadly force for developers and teams.

Building automatically testable software is crucial to move in an agile way with safety and confidence. Not doing it is often a trouble ticket. 

Automated tests provide us with a safety net and give us more certainty about new changes not breaking the codebase.

There are multiple practices aimed at building automated tests for the code we produce. Approaches like test-driven development (TDD) or behavior-driven development (BDD) are more or less accepted common-practice within the software industry, especially among Agile teams.

However, those techniques are too prescriptive regarding how we should build tests and functional code. In practice, I’ve found that these are all approaches that work well for me in some scenarios but not so well in others. 

Testing it’s a matter of finding a healthy balance between productivity, safety, and confidence. Yet, reaching that balance is not straightforward and depends on various factors: the maturity of our understanding of the domain, the design state, or how critical potential failures can be.

For instance, when we start a project, the result we look for might be too vague, and our solution could still be subject to rapid change. Beginning with TDD when we are in exploratory mode might not be the best use of our time just yet.

On the other hand, applying it when building a mission-critical system for air control would not only be smart and responsible but compulsory.

As a result, I prefer to adhere to the base principle of self-testing code as outlined by Martin Fowler and decide the specific approach to use depending on the scenario at hand.

Again, this is just a very arguable opinion. Actually, there is an interesting ongoing debate around this topic. If you’d like to expand on it and know where the conversation is headed, you can have a look at this discussion Martin Fowler, Kent Beck, and DHH held some time ago on this matter.