Test-driven development

It seems to make sense to write your code first and then to test it, as we did in our AddressValidator example above. Many people follow this approach. However, many others follow a process called TDD, where the tests are written first. Why do this? Let's take a brief aside before answering the question.

If you look at RSpec's official documentation, you will find that instead of the word test, the word example is used to describe the individual assertions to be found within the it block. Although it may appear less natural than test, in some ways example is more accurate. Automated tests rarely provide conclusive proof that a software system, or even just one of its functions, works. Most often, they contain a few test cases, which are nothing but examples of the code in action. Moreover, one of the main benefits of an automated assertion is to document the way the code behaves. Whereas test suggests a proof of correctness, example just suggests an instance of the code in action.

Coming back to the question of why someone would write their test before their code, we can apply the concept of the example. A methodical software engineer could benefit from documenting the code about to be written with some examples. Rather than adding these as comments in the code, the documentation can be written in the form of automated tests, or assertions. This way, as the code is being written, the tests can be run to give some feedback about how close, or how far, the code is to performing as initially expected.

If we refer to RSpec's home page, there is a link provided (https://relishapp.com/rspec), where we can read the following description:

We see that TDD is mentioned, but the first sentence identifies RSpec with BDD. Although a definition is given, it refers to three other methodologies, leaving us perhaps with only a vague impression of some fancy approach to software development. So what is BDD really?