How to Make Things Faster

Chapter 95. Automated Testing

Automated software testing is a significant advance of the twenty-first century. I don’t know how people do without it, honestly. Without automated testing, the world looks like this:

• A test is a big event. A big group congregates to “test the application.” Each user runs the application as specified in a huge text document and makes notes about whether the application correctly performed each tested function or not.

• Developers and their managers are leery—if not outright scared to death—of making changes to the code, out of fear of collateral damage that may not be detected until the next big test, if ever.

With automated testing, the world looks a lot different:

• A test is hardly an event at all. You initiate a test simply by typing a command like build test. Every developer will run at least a portion of the overall test suite several times a day.

• Developers and their managers make code changes all the time, because they are confident that any unintended side effects will be detected immediately in the form of test failures. Developers then have the information they need to repair the collateral damage or, perhaps, negotiate a change in the specification to be memorialized into the test suite.

It takes a lot of work to create an automated test suite. It begins with a testing infrastructure that is imagined and built at the beginning of the project. The test cases themselves are built continuously from the software’s initial requirements ...