To Test or Not to Test
Although most of this book assumes you want or need to test your software, you should not blindly assume that is necessary. Perhaps counterintuitively, the primary purpose of automated tests is not to verify new functionality. After you create the test, each time it runs it mainly serves to verify that you did not break existing functionality.
But what if you do not care about preserving functionality? If you write code that will be thrown away, consider whether you should write automated tests for it. Prototypes, proofs of concept, demos, and experiments may all have short and limited lives.
On the other hand, code that you want to sustain should be tested. If you test your code properly, you will increase your ability to modify your code safely. Code that you expect to base your business on and code that you want other people to use should be developed sustainably. This also means that the throwaway code just mentioned should be brought or rewritten under test if you decide to productize it.
You also need to decide how to test your code, and economics play a role in that decision. System and integration tests are usually cheaper and easier for highly coupled, low-quality code that changes infrequently. You will get more benefit applying unit tests to loosely coupled, high-quality code that changes often. The Automated Testing Pyramid presented in Chapter 1 assumes that you want to create sustainable software, but that may not always be the case for perfectly valid economic reasons. Or you may have inherited legacy code4 that needs rescue, in which case you will wrap it in characterization tests [WEwLC]—essentially a form of system or integration test—until you can refactor it into the form more conducive to unit tests.
4. Michael Feathers [WEwLC] defines “legacy code” as any code without tests.