TDD is an acronym for Test Driven Development and a jargon used in the tech industry. As the name suggests, the concept relates to the development methodology where before writing a piece of code, we first write tests that will verify compliance with the code.
Basically, TDD works on small cycles of repetitions, where each feature of a test system is created before. This new test initially is like to set up failure, because we do not have to implement the functionality in question in the first hand rather we write cases and then implement the functionality to make the test pass! That simple!
TDD is also known to be calm, yet a small samurai – not so fast! This means that we cannot just write another test just because we already have a passing test, i.e. we need to first refactor the feature we just wrote, that is, it must go through a small bath of “good practice” Software Development. These good practices ensure software with cleaner, cohesive and less coupled code.
1. Rules of TDD
The operation in TDD mode imposes the following four rules:
- First Rule: Always write the test before writing the code of the tested method.
You should not write the target implementation code as you have not written the code for the associated test. That is, it is necessary to have imposed the contract before entering the target code.
- Second Rule: Set in the test behavior and expected results of the test method.
The test code requires compliance with the business rule. Determine the expected result of the test code as the implementation code for the test does not exist or is not compiled yet.
- Third Rule: Simplify implementation code and make sure that passing the test is a success.
The implementation code should be simple in order to increase efficiency. This is why it is necessary to rewrite the code after all tests are successful. Furthermore, the tests must remain in success at the end of rewriting the code.
- Fourth Law: The coverage of the tested code is 100%.
100% coverage of the code allows us to avoid unnecessary or untested code that can be misleading.
2. TDD Development cycle
TDD is based on the preceding rules and allows for the next development cycle which goes by: Red>Green>Refactor
- Red: Initial stage of the TDD, where you write a test that fails for some functionality you will still write.
- Green: Already created with the test, is the time you need to pass the test, always remembering to go for the simplest solution first.
- Refactor: Step to eliminate redundant codes, remove couplings and make the code more readable design.
The developers perform this cycle at each change in the application code.
Continuous integration validates that the implementation code always respects contracts imposed by the tests. We offer both Test Driven Development and Behavior Driven Development. You can contact us for both services.
For more information on TDD, stay tuned in!