Test Driven Development: A Cooking Analogy

Imagine you are a chef who wants to cook a new dish. You have a general idea of what ingredients you need and what steps you need to follow, but you are not sure about the exact measurements, timings, and techniques. How do you ensure that your dish turns out delicious and meets your expectations?

One way is to cook the dish first, and then taste it to see if it is good. If it is not, you can try to fix it by adding more salt, spices, or other ingredients. You can also adjust the temperature, time, or method of cooking. You can repeat this process until you are satisfied with the result. This is called the “cook first, taste later” approach.

Another way is to taste the dish as you cook it. Before you add any ingredient, you have a small sample of what the dish should taste like at that stage. You compare the sample with the actual dish, and if they are not the same, you make the necessary changes. You do this for every ingredient and every step of the cooking process. This is called the “taste first, cook later” approach.

Which approach do you think is better? The “cook first, taste later” approach may seem easier and faster, but it has some drawbacks. For example:

• You may end up with a dish that is too salty, spicy, or bland, and you may not be able to fix it easily.
• You may waste a lot of ingredients, time, and energy by trying to correct your mistakes.
• You may not be able to reproduce the same dish again, because you did not follow a clear and consistent recipe.

The “taste first, cook later” approach, on the other hand, may seem harder and slower, but it has some advantages. For example:

• You can ensure that your dish is delicious and meets your expectations at every stage of the cooking process.
• You can save a lot of ingredients, time, and energy by avoiding or minimizing mistakes.
• You can create a clear and consistent recipe that you can follow or share with others.

Now, what does this have to do with software development? Well, you can think of software development as a kind of cooking. You have a general idea of what features you need and what steps you need to follow, but you are not sure about the exact details, logic, and syntax. How do you ensure that your software works well and meets your requirements?

One way is to write the software first, and then test it to see if it works. If it does not, you can try to fix it by debugging, refactoring, or adding more code. You can repeat this process until you are satisfied with the result. This is called the “code first, test later” approach.

Another way is to write the test first, and then write the software to pass the test. Before you write any code, you have a small piece of code that checks if the software does what it should do at that stage. You compare the expected output with the actual output, and if they are not the same, you make the necessary changes. You do this for every feature and every step of the software development process. This is called the “test first, code later” approach.

Which approach do you think is better? The “code first, test later” approach may seem easier and faster, but it has some drawbacks. For example:

• You may end up with software that is buggy, complex, or inefficient, and you may not be able to fix it easily.
• You may waste a lot of code, time, and resources by trying to correct your errors.
• You may not be able to reproduce the same software again, because you did not follow a clear and consistent design.

The “test first, code later” approach, on the other hand, may seem harder and slower, but it has some advantages. For example:

• You can ensure that your software works well and meets your requirements at every stage of the software development process.
• You can save a lot of code, time, and resources by avoiding or minimizing errors.
• You can create a clear and consistent design that you can follow or share with others.

This is what is meant by “Test Driven Development” (TDD). It is a software development process that requires writing tests before writing code. It aims to make the code simple, readable, and testable by tracking all software development by repeatedly testing the software against all test cases