In the series “Back to Front” our consultant Eoghain looks at the latest developments, releases and news in technologies from (you guessed it) the Back-end to the Front. In the latest installment, Eoghain talks us through test driven development.
Agile methodologies: Test Driven Development
Delving into agile methodologies over the years, one of the most important for me (as someone who largely works solo, yet needs to write clean code) is TDD. I’ve written before about mob programming which is great for rapidly developing high-quality code and generally produces great results, but what if you don’t have friends? Or just work with headphones on?
Well TDD is probably for you; using tests as a framework for creating high quality code really comes down to the fact that it forces you to understand requirements, it forces you to start with the simplest code and it instils the idea that failing a test is not a failure, it’s just part of the process of refinement.
Fundamentally TDD builds on the already well understood practice of Test First Development.
In the event that you aren’t already familiar with the process it goes a little something like this:
- We start with a failing test, one written for the simplest piece of functionality that needs to be implemented.
- Then we write the simplest piece of code possible to pass that test.
- Then that code is refactored, making sure that it takes into account all the requirements.
- Then we run the test, if it passes then we return to the first step, writing a new test for the next piece of functionality. If it fails we go back to the refactoring stage and continue with the testing until it passes.
Overall it’s fairly basic logic and results in very clean and high quality code.
But TDD takes things a step further, it starts by questioning assumptions about requirements or design by examining whether the initial design really is the best way to do things. In the event that your design and/or requirements are the best possible ways to do things then you proceed with TFD to create your code, on the other hand, if it isn’t, then you refactor your design to incorporate new requirements or eliminate anything you don’t actually need. The idea being that you are trying to refactor your design to incorporate those new requirements as simply as possible and to avoid any duplication of processes that will ultimately make your code clunky and inefficient. Once this is done then you proceed with TFD as normal.
TDD is not a one size fits all solution to all your testing needs, it simply is one solution to generate well tested, high-quality code. Used in conjunction with other Agile testing methodologies such as pre-production integration testing, allows teams to create extremely high-quality software projects that are (theoretically) fit for purpose… of course, further iterations will refine this further.
If you have any input on this topic, would like to get in contact about future topics or would like to discuss open roles drop me a line at eoghain.cooper@verifyrecruitment.com or connect with me on LinkedIn www.linkedin.com/in/eoghain-cooper-a0661449 Check out my previous articles here.
