How you can use Test-Driven Development
This article was written as an individual review assignment for PPL CSUI 2021
Test-Driven Development is an approach to software development where testing is created to specify what the program you are making will do. Test Cases are created for each function in your code to ensure your program is bug-free. The concept of TDD is you only write code when you have written tests and corrected failed tests.
There is a cycle of steps you would need to do, to perform TDD. The first is writing tests for the functions you are going to make, then run the tests to see if any new tests failed. After you have made tests, you can start writing your code. Run tests on the code you have made, if any fails, refactor your code. When all tests have been passed, you can repeat the process until your program or application is complete.
As a software development student, at first I do not understand why there is a need to use TDD or what the benefits it. TDD can help better code design and improve code quality, writing tests first help developers define the goal that they want to achieve and give an estimate on how each functionality will match with others. TDD also creates a detailed project document, when writing tests for a requirement, the developer creates detailed specifications so in the future they would not need to create heavily written documentation all at the same time.
Above is an example of tests I made for my PPL project of findsOneWidget, this test is used for finding a certain widget from a key.
For example in my PPL project, when I want to create a registration functionality for my application I would create tests for each UI item, input validations, and other functions first before implementing them in my code. After the tests have been made and my code has been tested, I will errors that may arise when testing. After each test has been passed and my feature is implemented successfully, I can start working on creating a report feature.
TDD helps in Agile
This PPL project me and my team are working on is developed with agile so requirements and implementation can have changes during the development phase. In this phase, the code I make will be used and developed by other group members so that testing it makes the code easily maintainable and keeps code consistency in case of changes. Because of this, Codes generated by other group members are more clear and understandable. It also allows us to work quickly and smoothly because it is faster to understand the code we are going to use.
Above is the Sonarqube page showing bugs and code smells after implementing the code in my PPL project. In this example, there are no bugs or code smells from my code. The Good code quality and good application make product owners and clients feel satisfied with the temporary application and have no complaints about the application.
TDD Cycle
There are phases when you are developing code called the red-green-refactor cycle. The red phase is when you’ve only made tests for the code and function that you are going to make. The green phase is when you’ve made the codes that the tests you made in the red phase have been passed. Refactor phase is when you need to make changes to your code or make improvements while maintaining the test's pass. There are also moments where you only change or add dependencies, you can label this as chores.
Meet the F.I.R.S.T Principle
When I make tests, I always try to meet the F.I.R.S.T Principle and get the benefits I have mentioned before. Here are the details of the F.I.R.S.T Principle.
- [F]ast, tests should be fast otherwise they will slow down my development/deployment time.
- [I]solated, Never write tests which depend on other test cases.
- [R]epeatable. A repeatable test produces the same results each time you run it.
- [S]elf-validating. Each test must be able to determine that the output is expected or not. It must determine it is failed or pass.
- [T]imely. As I said before we must create the test in a timely fashion which is before the code is production-ready.
References:
https://www.codica.com/blog/test-driven-development-benefits/