Test driven development. It’s a technique where you know what the behaviour or result the code should produce, but you haven’t written any producing code yet.
So you break down the problem into small steps which each produce a testable result or behaviour that brings you closer to what you need.
And before writing any implementation for each of these small steps, you write a unit test which checks whether an implementation would execute this step correctly. Once you have that test set up, you can start writing the implementation, keeping it as simple as possible, and running the test until it passes for your implementation.
This keeps going in a cycle.
Once all your tests pass, provided you’ve written good and correct tests for every step there are several benefits of this approach:
you can be quite confident that your code works as expected
making changes to existing code is much less scary, because you can change the thing you need to change, adjust or add tests accordingly, and rerun all the other tests to make sure everything else still works as expected
there is a big psychological benefit when you force yourself to define exactly what you expect the code to do before you actually write it
it can help others understand what the intent behind the code is by looking at its expected behaviour
The downside is that it takes more time to write tests for everything. But for complex applications, it will save you a lot of time in the long run if the code will be changed very often in the future or is complicated, because many bugs will be caught by your test landscape.
Test driven development. It’s a technique where you know what the behaviour or result the code should produce, but you haven’t written any producing code yet. So you break down the problem into small steps which each produce a testable result or behaviour that brings you closer to what you need. And before writing any implementation for each of these small steps, you write a unit test which checks whether an implementation would execute this step correctly. Once you have that test set up, you can start writing the implementation, keeping it as simple as possible, and running the test until it passes for your implementation. This keeps going in a cycle.
Once all your tests pass, provided you’ve written good and correct tests for every step there are several benefits of this approach:
The downside is that it takes more time to write tests for everything. But for complex applications, it will save you a lot of time in the long run if the code will be changed very often in the future or is complicated, because many bugs will be caught by your test landscape.