Introduction to Test-Driven Development
As software developers, we may (or may not) have heard about this software methodology. Software testing is not a new method. It’s been invented in the ’90s. As the program gets more complex and has so many features, it’s easier for the program to break down in a production state. When that happens, every developer meets with a headache as a bit of change in one function can alter the whole program and need so many adjustments. This thing makes the software unreliable. Also, fixing a bug in the production has so many cost and even can make the user can’t use the whole program.
When that happens, every developer meets with a headache as a bit of change in one function can alter the whole program and need so many adjustments.
That’s why in 1998, one of the article about extreme programming mention, “we usually write the test first”, and from there, Test-Driven Development starts to grow. Until finally, in 2003, Kent Beck releases a publication, “Test-Driven Development: By Example.”
What is Test-Driven Development?
Without Test-Driven Development, usually, the developer will implement the features first and then check to see if there is any bug. This way, as I mentioned before, every change that was made after the feature is complete will have the probability to break the entire code.
With Test-Driven Development, as the name suggests, it is mandatory to write the test for specific features first and then write the implementation code later. TDD has a unique three unique steps, and that is “Red-Green-Green”. What this means is that every developer should write the first and then run the test. For the first run, the test must fail, as there is no implementation code for it. After that, developers can start to write the implementation code. For this step, our primary goal is to ensure that the test will pass, so the cost (such as complexity or memory usage) is not substantial in this step. The last step is a refractor. In this step, our previous code must be optimised and, if there are any unusual naming or unused variables, it can be deleted to make the code more memory-friendly.
So, in short, the basic principle of Test-Driven Development is to make the test -> make the code to pass the test -> optimised the code.
First Step: Failed the test
It may sound ridiculous at first, but the first step to Test-Driven development is writing the test and making sure that it fails. Some points were encouraged in this step, and that step is :
- Write small — It is essential to write your test one features or function at a time. This way, the implementation code won’t be too complicated, and if there’s any error, you can detect it immediately.
- Cover any possibilities — Say that your code should have three expected output. The best practice is to take the test for those three scenarios as well. So that you can be sure that your code will be work as you intended.
- Don’t overdo it — Even though you are encouraged to test every possible output of your code, it is best if you don’t test any trivial codes. Too many tests for trivial code will make the test unreliable to the core function of your code.
Second Step: Pass the test. Anything is allowed!
After we take our first test, the next step would be to pass that test. In this second step, the essential point is that you have to pass that test, so anything about program cost, complexity, and anything else is not mattered. This is also to speed up the development process, and sometimes the best idea for the program algorithm can’t come naturally.
You need to note that you have to pass the test and ensure that your implementation won’t make the test unusable. This is why practice is your best friend. The more we practice writing the test first, then the implementation will ensure that we can make a good test and ensure the implementation code won’t violate our unit test.
Final Step: Optimised our code!
We have written our test, we have implemented it, now it’s time for optimisation. As I said earlier that in the second step, the goal is to pass the test. Complexity or cost doesn't matter. In the final step, it’s time to refine our code or, in other words, refractor.
In this step, we can look for unused variables, faster algorithm or renaming our variable so that our code is readable and easier to maintain in the future. We always need to remember that our refractor code should never add a new feature or omit an existing one. This way, when we have done with the refractor, the test is still reliable.
Benefits and characteristics projects that implement Test-Driven Development
We’ve known what Test-Driven Development is, the implementation, and now, of course, we’re asking the benefits of Test-Driven Development. Benefits of Test-Driven Development :
- Because we write the test first, this makes our program have a significant decrease in defect rates. Even though the cost of project initiation is higher, it is better to detect any bug in the development stage than in the production stage.
- Test-Driven Development also said to increase code qualities, whether it’s about complexity or clean code. Because after every implementation, the developer will review their code and make a refractor.
The main benefits of Test-Driven Development are a significant decrease in defect rates and better bug detection in the development stage.
After we know how much the benefits of TDD. I will show you the example of the test code and the code that I test for my PPL course.
Below is my test code for the signup (in this case the user is a farmer) and login function to the system. The basic idea of testing a program is you have to test the program output, is it correct the way you want it or is there any program detected by the test?
After we write our test and make sure that it’s failed, we can start to write our implementation. Always make sure that your implementation won’t break the existing code. It takes time and practices as I said before, so if you still confused or wrong the first time. Don’t be discouraged! Below is my implementation code for the test :
After we test our code, we can do a double-check to check whether our implementation already correct. There are a lot of tools to do that. But for this project I use coverage, you can get it easily using
pip install coverage
And after that, you can use:
coverage run --source="." manage.py test
To generate the report to HTML format, use:
There should be a folder named htmlcov on your parent project directory, open that and search the HTML file that contains your desired test. The green line shows the code covered by the test, and the red one show the uncovered code.
Lastly, the project with Test-Driven Development has its character. Some of their characters are:
- Version Control log will show every Test-Driven Development stage and any change that was made. For example :
- Code Coverage badge, every project that has a Unit Test in it will show the test coverage. For Example:
Feel free to share or comment on any new suggestion to improve further my article or my knowledge in Test-Driven Development methodology. Best regards, Fredy.
Agile Alliance. (2021, March 4). What is Test Driven Development (TDD)? | Agile Alliance. https://www.agilealliance.org/glossary/tdd/#q=%7E(infinite%7Efalse%7Efilters%7E(postType%7E(%7E’page%7E’post%7E’aa_book%7E’aa_event_session%7E’aa_experience_report%7E’aa_glossary%7E’aa_research_paper%7E’aa_video)%7Etags%7E(%7E’tdd))%7EsearchTerm%7E’%7Esort%7Efalse%7EsortDirection%7E’asc%7Epage%7E1)