Test-Driven Development — The code is guilty until proven innocent
I relocated my workstation from the office to my residence on Thursday and now I am always in front of my screens. All four of them. The first thing I did was review my knowledge of Test Driven Development (TDD), understand its foundations and motives, and most importantly, how I can utilize it in building software.
I will detail a part of my notes here and share a link to the application I built implementing TDD.
Let’s get started, shall we?
Test-driven development (TDD) is an Agile software engineering methodology that emphasizes the use of short and frequent development cycles. Requirements are turned into extremely detailed test cases. The production code is subsequently implemented to enhance and pass the tests.
Unit Testing
Writing unit tests is part of test-driven development. Unit tests examine the smallest components of a larger system. These tests are found at the very bottom of the testing hierarchy. They are created and implemented as early as possible, and they are re-performed as frequently as required.
Red, Green, Refactor
When it comes to test-driven development, the term “red, green, refactor” is frequently used. An Agile engineering pattern is red, green, refactor, which calls for a short development iteration, or cycle, to reduce broad assumptions about how your code should function vs how it does now.
RED: It’s the very first step in the development process, even before any code is written. You create a test that fails. If I don’t have any code, why would I write a test? As a developer, this encourages you to focus on the problem you’re trying to solve rather than the code. It also helps in splitting the problem into small pieces.
GREEN: After you’ve created a failed test, the second step is to turn it green. That is, make the failed test pass. You should write the absolute bare minimum of code to get this test to pass. This leads to a smaller codebase, which means less code to maintain over the lifetime of the app.
REFACTOR: Remember that ugly code you wrote to get the test passing? This is where you get to clean it up. Refactoring is the technique of restructuring code by modifying its internal functionality, without changing its external behavior. Feel free to rename variables, extract logic to functions, or even introduce a software pattern as the code matures. Don’t forget to run your tests to ensure that you didn’t accidentally break functionality while refactoring to the most eloquent code.
As the developer implements their requirements, the test-driven development workflow is generally carried out locally on their workstation. Once they’ve finished implementing a feature, they’ll submit it into the source control system, which will start a CICD build job. The build task should re-run the entire test suite to ensure the integrity of all components under test, including all individual classes and so on. This should occur before any additional integration or end-to-end testing.
Utilizing my refreshed knowledge on TDD, I built a Java library that converts bitcoin price to USD, GBP, and Euros price equivalents. You can find the source code on my Github by clicking the link below.
References
Big thanks to Jeremy Cook from Cloud Academy for having a comprehensive and practical course available on test-driven development. You can find a link to the course below.
