Test Driven Development: A short introduction

Guymonahan
4 min readJun 7, 2021

Imagine trying to learn a language where you are learning either all of the words or understanding the intricacies of grammar before diving into the words. It could in theory work, but it doesn’t make much sense when it comes to how the world works when we are taught. The words and grammar come in parallel, complimenting each other, and helping to establish a bridge to more complex or detailed words and structure. In a lot of ways dealing with code is not too different. We have much of the lexicon and understand (sometimes) how to apply it for the application we are trying to execute, but in much the same way that the initial way of doing one thing, then moving to the next doesn’t make sense to learning a language, it is so when it comes to developing ones code. Within Test-Driven Development (TDD) we have a method that hems to the natural understanding of how to write code as if we were to write a short story. We wouldn’t begin editing once we finish the story, we would possibly brake the edits up by paragraphs so that they are more manageable and better at seeing what went wrong within that segment and how that changes the story of both the author and the coder. In this case it will be the “unit test” that we work with here.

TDD is a series of steps, a mindset, and an approach all at once.

  1. We need to write a test: We need to work within the confines of the objects that we establish whether in a class or some other method. We can setup the case studies to make sure it will be able to interact with other stories that the user might develop.
  2. We need to run the test: At this point we want to make sure that just a single test is all that will be sent back when we run and it should be a error. We want to make sure that the negatives are established ahead of looking. The error message will give clues on how to best handle the situation at hand. As we go through there will be other tests added to the end of the unit testing row, thought it should be noted that each unit test should be an independent entity with no reflection of its behavior based on the other tests.
  3. We need to fix the code: We need to fix the error. If you are able to execute a function that will return a pass, then you can move on. In various situations, such as classes, you will need to independently check each of the other functions that it also tests.
  4. We need to rerun the test: Now we have a bunch of executables that have all been independently vetted, lets see if they run cohesively without returning an error.
  5. We need to refactor the code: This might be a part of the previous step, but it just means to make sure that the code is clear, readable, and that it is organized in a logical way.
  6. Repeat

Some of the many benefits and drawbacks of TDD are paradoxically found together. It is a much slower way to code, but that is not always a bad thing, and you get faster at it with practice.

  1. It is faster when you get used to it, but it will be slow until you get better at writing code. Though by doing it this way it will become a second nature.
  2. Fewer surprising bugs and disasters. One of the most frustrating things one can encounter is writing a lot of code, it sends back an error, and while it says which line the code breaks, sometimes it might have a cascading effect on the other code that you have written that might not have it send back an error, but rather change how it executes the way that you want. Using TDD since each of the processes are independently tested out the chances of these kind of catastrophes from happening lessen.
  3. By taking time with the code, you can better comment on the how and why. This is important as you will be able to better segment the code into units that will be better understood in a few months when you look back on it.

It isn’t a catchall, and by no means is this the optimal method to engage with any and all code, but rather a method that will be yet another tool to help one code. Like anything else by using it you will be able to better understand where it will excel and where it will be a millstone in your progress.

--

--