|
view as a single page
Testing in Software
While there are many kinds of tests that we write in the world of software, there are generally two with which developers
spend most of their time: unit and acceptance tests.
Acceptance tests tell you whether the thing(s) they validate are useful in some way. They tell you whether or not your
application does the job it is required to do. They tell you if your components are fast enough. They are all about
validating that the software fulfills business intent.
Unit tests, on the other hand, prove that your system was built correctly. They do not directly test design but they are
tied to public interfaces closely enough to test behavior at a relatively fine grain. Unit tests are about proving that
the developers’ intent is expressed by the thing(s) they test.
It is generally accepted that unit and acceptance tests which validate programs and components confer confidence upon an
entire species – all of the binaries – rather than just the instance they are testing. Yet, these tests do not directly
validate your code – which is the definition of the species. Instead, they test the output of your code, the definition
of an individual. So how is it possible for a unit test or an acceptance test to give us confidence in the species as a
whole?
The answer is reliable builds. Because there is so much fidelity in the build and deployment paths defined for programs,
the object under test ends up being a good representative for other objects of the same kind. When you test something
that is prototypical, you gain an understanding of its archetype.
Related Links:
Introduction to this Series,
Part I: Evolution,
Part II: Deployment,
DataConstructor
|