How does software test itself?

Software tests itself through small programs that check the main program. A programmer writes a unit test: a short piece of code that runs one small part of the software with a known input and checks that the result matches the answer they expect. If it does not, the test fails and reports it. Because the checking is automated, it can be run often and without staffing cost.

The pattern is simple: the test, the function it tries, and the expected value. The programmer writes into the test a result that is known to be good. When the tests run, a testing framework logs every one that fails and gives a summary. Many tools show a bar that is green when everything passes and turns red when any test fails, which is where the phrase green build comes from.

This matters because a program can run perfectly well without doing the right thing. Manual testing is too slow for software that changes all day. Some teams go further and write the failing test first, then just enough code to make it pass, then tidy up and repeat. This is called test-driven development, and Kent Beck, who is credited with developing or rediscovering it, says it came from an old programming book.

Tests are not magic. Programmers often write 3 to 5 lines of test code for every line of code, and no amount of testing can check every path through a program. But a good test suite lets you change code with confidence. Martin Fowler imagines a mischievous imp that can secretly alter the code but not the tests: if the tests stay green, they are not good enough.