Introduction

Tests are always ordered last in both books and framework documentation, because they don't contribute directly to what end user interacts with. This approach creates too many developers who simply don't know how to automate their tests. It takes the few who have seen first-hand through the crystal ball of tests, to appreciate how indispensable it is. It is the only insurance that can give a maintainer the confidence required to alter existing code without fear of damaging other parts of the system. It equally forms the basis for bravery behind presenting features meeting the business at its point of need.

A lot has been said, both across chapters of this documentation and in other frameworks, about providing methods for observing examinable or assertable functionality. But very little is mentioned concerning the key thing which is coding patterns those methods can properly be applied to.

While some TDD adherents may attempt to downplay the tedium of tests, in sincerity, it can take careful commitment to get right, depending on the test type. In some cases, it can entail database seeding, mocking object states, and expecting certain outcomes, which is one of the parts we are most interested in. But putting it all together is what distinguishes a codebase one update away from disaster, from another.

The essence of these steps is not because automated testers are masochists. Where necessary, each technique is deployed toward the common goal of simulating behavior of the code under the test, before it gets to production. It's not magical that tested code is more resilient, more reliable than its alternative, gives its maintainers greater confidence, etc. The simple change with a world of difference is that one of those codebases has been exercised by the developer in a replicable way, while the other is left to the fate of the software's user.

Given this understanding, an assumption that a program may work fluently in the absence of automated tests is analogous to an actor's absurd assumption that they'll get the stunt right in one take. It eventually happens for the most experienced among them but is neither reliable nor looked upon as a sustainable means of filmmaking, rather as the occassional anomaly.