Test-driven development as a school of thought

Test-driven development as a school of thought

Software is eating the world, and so is the world of software development constantly changing.

One way of developing a project would involve

Nothing, but a typical waterfall model scenario, coming with it’s obvious pros and cons.

TDD or Test driven development follows a similar approach to this, which would be gathering the requirements, doing the analysis, modelling the desired system before writing any code for it.

To write a test, you will be gathering what the input should be and what the output should be(on a very high level of thought).

Once you have some knowledge about the what needs to be done, you will be able to write those fine grained requirements in the form of tests.

When you are writing those tests, you will figure out the gaps and misunderstandings in the requirements before you’ve committed those gaps and misunderstandings to the project in the form of executable code.

What you would gain immediately after adopting TDD

This is because of the fact that, you are only implementing the features that are required immediately in the first iteration.

The problem comes when you would want to refactor certain areas of your code base, and this is where TDD shines if you ask me. You would be confident about the functionality as you would only be testing the end behaviour of your program and not the implementation details of how is it being achieved in unit tests.

This way, you can easily go with the Red Green refactor cycle.

If you’re covering all the edge cases as part of writing the tests, you are already sorted in having a system which has minimal bugs in terms of functionality.

Something which I have been trying to follow lately is to not check in any production code, before writing the tests for it.

Write the specs, run the spec, let it fail (red). Implement the interface that you’re testing (make the code green), and then refactor.

Some of the things which I noticed worked well while writing tests were

Testing is like security, you can never be 100% per cent sure whether you’ve got it, but it surely adds to the confidence on what you’ve built.

So let’s say if you have written some 20 tests, and all of them pass, you wouldn’t be sure if what you have written is correct or not. But let’s say you started with all them being in the red state, you would have much more confidence in the system that you have built.

This back and forth does take time. But it’s a process which tries to address the concern of having doubts about whether what you built is a resilient system or not.