Test-Driven Development Principles
For people learning Computer Science, we all have been told about Test-Driven Development, what is it about, and how it is a must to implement them in software development, countless of times. To review it briefly, here’s what TDD is.
Test-Driven Development
Here’s the cycle you must have seen countless of times.
Test-Driven Development is a development flow which a developer will start writing a test case for a feature it wants to implement first, before writing the actual implementation. After writing a test-case, the developer will write the feature’s implementation until it passes the test. After passing the test, the developer will refactor that implementation for improvement such as optimization and clean code, while maintaining the code to keep passing the test. After finish refactoring the developer will repeat the process again for the next feature and so on until every feature is finished.
The Problem with that damned cycle
While learning Test-Driven Development, I was told that once you create a test-case, the only thing left to change is you implementation code, not your test case. Your test-case stays the same just like when you first finished it until the end of development. If you edit your test-case, it means you fail to implement TDD and should feel ashamed about it, which to be honest I found absurd.
Rewriting test-case is part of the development. As development continues, you have a design for your feature and you made test-case for it. If after many implementations and that test-case keeps failing, maybe that design has flaws and you need to rethink about it, therefore you need to rewrite your test-case for your new design. This way, you improve your project design and discover better ways to implement your project features.
Even so, I don’t think of dropping TDD.
The Principle
The reason why we put such restriction on changing our test-case is to set us a blueprint or a guide for our design. It’s easy to get lost when writing an implementation code and lead us to make unnecessary implementation, leaving us with bad code. With setting up a good test-case from the start, we can assure that when we write our implementation, we won’t get lost and we can be confident that our code will work well.
But there’s a flaw where the guide we set up may not be perfect, which lead us lost. This is why we need to rewrite a better guide in hopes it will lead us to our goal, but remember, changing your test-case to fit your implementation doesn’t count, it will only set you up to fail. That’s what I think the principle of Test-Driven Development really mean.
