test-driven development

I’ve been working on a homework assignment where I’ve been tasked with undergoing the process of test-driven development while working on a code kata where I am to count the number of times each word in a string appears whilst ignoring special characters, spaces and new lines.

To summarize what test-driven development entails quickly, I consulted a blog post by Denis Peganov. Basically, when you do test-driven development, you write tests before you write the code. In practice, this means you have to figure out what the inputs and outputs should be for the code you’re working on, then organize the order with which you should be fulfilling tests in. Denis also mentions the cycle of test-driven development with the red, green and refactor phases. You start with a failing test in the red phase, write the minimum code to make the test pass in the green phase, then, as the name implies, refactor the program to enhance the program’s design if necessary. Denis goes further to make a great point that the iterative nature of test-driven development lends itself to modularity and can create a flow to the evolution of the codebase where this strategy is being applied.

I have to say, doing this in practice is fairly enjoyable up until the point where you have to rewrite everything. The flaw (while it is based upon the practitioner of this strategy of software development) is that if you ‘mess up’ the order of the tests, you can reach a point at which your design needs to change so drastically that you are effectively working backwards. This doesn’t necessarily mean that the strategy is bad, it’s moreso that it does require practice and experience in order to have a smooth development. It also requires the willpower to refactor massive chunks of code when you reach a critical refactor point, which for me it may just be that I’m rusty with regard to coding.

Regardless of this critique, test-driven development does seem to be the best of both worlds. Not only are you able to properly plan software from specifications, but you also get to actively see the results of your code while developing it. It seems incredibly efficient in comparison to other philosophies of software testing, and for me it’s honestly more engaging to write tests and write the code than just writing tests and reading the code that already exists or the specifications alone.