TDD, test driven development, is the practice of writing failing test before you have working code. This practice helps you to write only the code that is required and while also given other advantages which I won't cover here. What I do want to cover is how recently I found my self being forced to do TDD.
Recently I was working on a CLI tool command for a project. In the finished version of the command the flow in code execution is in the following order.
Download a given repo.
Go to a path in the repo for a given product type.
Get all the folder names from the path.
Convert the the folder names into semver versions.
Calculate the supported semver versions.
Return these versions to the user.
As you can see over all the steps are not hard or complicated but there is an order to them, each step leads on to the next. So when the first step of download the repo just does not work due to my misunderstanding of how the git package was working, I became stuck. For the other steps I know what format the input data should be or at least I know what it should be like for step 3.
So as not to be stuck I started by writing a test which has the mock input values and expected outputs of step 3, "Get all the folder names from the path". With the test in place I could start to write the functions to get the test to pass. By starting that this stage it meant I was not still blocked by the first step but more importantly it meant that I had no real data to work with. The only way I could test my functions was by unit tests.
One by one I was able to do each step. Writing a unit test with the inputs I expected to have and the output I wanted to get. Of course with the tests in place it made it easier to test the edge cases and mock out what happens with many different semver versions being picked up. When the other steps were finished I had good confidence that the smaller parts of the command all worked.
Getting back to the block step of downloading the repo, it turned out I was passing the wrong flags at one point. A simple fix but at the time I just could not see it. After the getting the block stages working the next stage was to test the CLI command for the first time. Writing a test for this was not as easy but it didn't need the validate the output, that is done in the other steps unit tests but to validate the inputs. During the writing of the functions of the steps I was also creating the function for the CLI command. While the command could not work till all the steps were done, it was wired together and which worked about 90% correctly on it's first run. Yes, even with all the unit tests I made mistakes but it was so easy to debug how I had wired things up wrongly at this stage as I trusted the unit tests for the different parts before hand.
This all seems like a good thing but it's not where the great power came in. As part of the code review process it was noticed that in the repo there were newer semver versions that were not yet released or in production so there for not supported. This all meant that I had to edit the command and add this filtering in. This work would have being some where in between steps 4 and 5. There needed to be three or four new functions added each of which could be unit tested. After doing the TDD for the first review, adding in these new comments became very painless. The trust in the test allowed the new feature to be quickly created and tested. Even the reviewer was impressed by how quickly the changes where implemented.
Conclusion
We are not perfect, we will make mistakes and any change we have to reduce the risk of that happening should be welcomed. TDD is not easy to force your self to do but not having access to actual real data, in this case the repo, can make it easier. You may not be able to do it every time but when you can it's so nice. From now on I will try add this into my work flow but on some project this might just be too hard at this time.
