Let’s say your job was to write a program that types to the screen the word: AWARE.

If we skip TDD, we just build our program to output the letters A, W, A, R, E, and we’re done.

Well, guess what? We aren’t done because a good developer realizes feedback is needed to prove the program works. So they run the program at least once to observe that it works. They may even confirmed their understanding of the spelling by looking at a dictionary or 1asking a colleague, and then publish the program.  Great!  Notice in even this simple example there is a problem–the developer did *manual* testing when observing the result to decide if the program worked. Two months later, a different programmer is asked to add a colon to the end to make the meaning clear.  They develop the code and again, manually look at the word “AWARE:” probably coming to the same understanding of the spelling as the previous developer, and then they publish the code.  However, often, the later developer is focused on only the colon at the end because that was their contribution. This third developer notices t