Rethinking Agility in Databases - Part III: Testing

Skip Navigation Links

Rethinking Agility in Databases 2/29/2008 2:03 PM

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.

< Introduction Creating a Species >