If you do not have tests, how do you know your code works?

**Edit:** the assertion that tests cannot *prove* that the code *works* fails to define one crucial term, namely *works*. What does it mean for a program to work? If you keep this term vague, then there is no way at all to prove or be sure that any program works. Ever.

On the other hand, you can define *works* as "behaves according to a specification". Now you can not only use tests to show that code works, but the tests themselves can serve as an executable specification of your code's behavior. In other words, a well written test suite defines what *works* means.

This way of thinking also forces you to re-examine the meaning of a *bug*. If your code passes all the tests, then there are no bugs in the code. If, despite that, the system does not behave as it should, then its behavior is not correctly specified. I. e. the bug is in the spec, defined by tests.

This approach to software development decouples the functional specification of a system from its implementation, which, according to every software engineering book in the world, is a very good thing. At the same time, this approach ensures that your implementation always corresponds to the functional spec.