Software Methodology: Test-Driven Development(TDD)
“Programming is like exploring a dark house. You go from room to room to room. Writing the test is like turning on the light. Then you can avoid the furniture and save your shins (the clean design resulting from refactoring). Then you’re ready to explore the next room” — Kent Beck
Test-driven development is a discipline, if not a methodology, of software development focused on understanding the requirements and what would your software do about that, instead of jumping straight to code implementation. You first create a test (which intended to fail, of course) about what you expect your code would do, then implement the code to make the test passed. Seems too much work right? Why can’t we just move right away to the coding? It’s so boring!
Hold it up a little bit, before your mind wandering too far about this methodology, you must know that this TDD thing might gonna save you from unnecessary time-consuming, head-aching, eye-tiring, sleep-reducing works later, if error emerges.
Why is that?
Before that, we will talk about the steps of implementing TDD. Those are:
- Create test, which usually named RED. We create the test for a small, specific behavior we expect, run it and it has to fail (else it’s not a TDD, of course).
- Implement code, or the GREEN phase. We implement the minimal code to make the test passed, or in other word we write the code based on the behavior we expect when we write the test. P.S: even when the name is GREEN but GREEN is not always the color we would see after we run the code, well, what can we say, we’re only human. GREEN is what we expect we will get after we implement the code. If the test still fail, then continue to make changes until the test passed.
- Enhanced your code readability, re-usability, or we can just say, make it better. It’s called the REFACTOR. Since we only focused on making the test passed at the GREEN phase, there must be some unnecessary or improvable lines in our codes. This is the phase to do some improvement to the codes, simply to make it cleaner and easier to understand.
Get back to the ‘why is it important to implement’ question, as you can see the developers implementing TDD tends to work on small steps, with small amount of code at a time, making it easier to identify errors, since the errors would be specific to a particular part of codes, and we’ve already make a test for it too, so we most probably know what went wrong. Plus, since we work on minimal code at a time, it will also make our code cleaner and simpler, even after the refactor, because all the refactor phase do is to make the code better and the functionality enhanced, but of course without went too far from what we wanted. The tests can increase developers confidence, because passing the test makes them sure that they are doing the right thing, and did not went too far from the requirements. Besides, which programmer doesn’t get hyped when getting some green outputs on their screen, indicating their code succeed running and passed the test?
TDD, however, have some downsides in it too. The constant focus on passing the tests, plus the tendency to make every step as minimal as possible, would make the refactoring phase a huge work to do. Of course we want to make our code super efficient for the feature, but we also want to make some more functionalities to the feature as an additional value. In green phase, this intention is (not so, but kind of) restricted so it all went down to the refactor phase. It can also slows down the development, because for any feature we want to implement we have to make a test first, and not to mention running the test to check the outcomes. TDD also requires every project member to (at least) understand the whole process, especially for the test making. We have to make sure everyone understand what to do, step by step. In reality, the project requirements rarely stays the same and constant. There’s always changes to it, and requirement changes would also mean test changes. It makes us have to check and change the test continuously, and don’t forget about the test that has to be removed. Looking back to the time when we made those, it took a long time to make it and now it just gone!
As every other development methodology, TDD have upsides and downsides. And of course, every type of project and team members would require a different methodology approach, so whether to implement TDD or not, it’s totally your (or your team’s) choice to make, I’m just here to give an insight, plus, to be honest, a score for my Software Project course.
I am totally open for any feedback you might want to give to me, and I will try to respond to it as soon as possible. Have a good day!
