A software test is an automated procedure that makes assertions about a piece of code and then reports the success of those assertions back to you. A test may make assertions about anything from an individual function to the behavior of an entire feature.

Tests, much like the rest of our code, deal in layers of abstraction and granularity. If we were to test a car abstractly, we may simply seek to assert the following attributes:

• It has four wheels
• It has a steering wheel
• It drives
• It has a working horn

Obviously, this is not a very useful set of assertions for car engineers, as these attributes are either incredibly obvious or insufficiently described. The assertion It drives is important, but without extra detail, all it expresses is a generic business-oriented objective. It's similar to a project manager asking for a software engineer to ensure that a user-login portal, for example, can allow users to log in successfully. It is the engineer's job to not only implement the user-login portal but to derive working tests that successfully investigate the truth of the assertion users can log in successfully. And it is not always easy to derive good tests from generic statements.

To correctly engineer a test, we must take the generic and abstract requirements and distill them to their granular and unabstracted details. In the case of us asserting that our car has a working horn, for example, we can distill it like so:

When we start to add crucial detail to our assertions, they become useful to us. We can use them as both guides of implementation and confirmations of functionality. Even with this added detail though, our statement is only an assertion or a requirement. Such requirements are a useful step in the design of software. In fact, we should be very reluctant to even begin implementing software until we have such levels of specificity.

If a client were to ask you to implement a payment form, for example, it would be wise to gather the exact requirements: what types of payments shall it accept? What other customer information requires collection? What regulations or constraints are we beholden to in our storage of this data? These expanded requirements then become the yardstick via which we, and the client, will measure completeness. It follows naturally that we can then implement these requirements as individual tests to confirm their existence in the software. 

A good testing methodology will involve tests for all distinct parts of a code base and will provide the following benefits:

• Prove fulfillment: Tests allow us to prove to ourselves and our stakeholders that expectations and requirements are fulfilled.
• Have confidence: Tests allow us and our colleagues to have confidence in our code base—both that it works correctly and that it can accommodate changes without faults arising unbeknownst to us.
• Share knowledge: Tests allow us to share vital knowledge about how parts of our code operate together. In a sense, they are a form of documentation.

There are many second-order effects of a good testing methodology as well. The increased confidence in the code base by your colleagues will mean you can be more productive and make more significant changes more quickly, cutting costs and pain in the long run. The sharing of knowledge can enable both your colleagues and your users to perform their actions quicker, with more understanding and less overhead in time and expense. The ability to prove fulfillment enables teams and individuals to better communicate the value of their work to stakeholders, managers, and users.

Now that we've discussed the obvious benefits of tests, we can discuss how we should go about authoring them. At the core of every test is a set of assertions, so we'll now explore what we mean by assertion and how we can use assertions to encode our expectations.