Test-Driven Development

Test-Driven Development is a style/ practice of programming. Mainly targeted at developers, it was introduced by Kent Beck one of the 17 original signatories of the Agile Manifesto in 2001.

“The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I’d written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, “Of course. How else could you program?” Therefore I refer to my role as “rediscovering” TDD.” — Kent Beck

TDD approach helps create high quality and maintainable code in which the programmer would first

• write unit test cases then execute them and validate them, next
• write the code to fulfill the test case and run it
• if it doesn’t pass the test cases refactor the code and run it again

Getting into a bit more detail. First, the programmer would write unit test cases to cover the requirements given before programming the relevant block of code and then execute these tests which obviously will fail as there is no code for the test to run.

The reason being for the programmer to first run the test is to validate the unit test written. The next step is to write the simplest code /smallest amount of code ( like bare minimum) to fulfill the test cases, and run the code.

This might pass the test if so yaaayyyyy if not it’s time for the programmer to refactor the code and fix the issues to pass the test cases and then run the code if the test fails again it means he has to repeat the process and refactor the code.

In the stages of refactoring the programmer is advised to not add more code but to fix the code written as adding more code might affect the aspect of keeping the code to its simplest form. But hey, this is just some advice to help keep your code simple not a rule so if worst comes to worst try and add as little possible code to pass the test cases.

Produces high-quality code because there is a clear purpose in every code block illustrated by the test cases.

The test cases could be referred to as a document for testers and developers in regards to the functionality thus giving them an idea upon reading

Defects in change requests could be minimized to a great extent as the defects would be triggered when the test cases fail before the developer releases them for further testing by the QA.

TDD also greatly helps to minimize regression defects. Regression defects are caused when a new implementation breaks old functions. With TDD any new implementations that could affect existing functions would be detected prior to release when the test cases written by the developer are run thus avoiding a lot of hassle in releases.

Advantages

• You only write code that’s needed — Only the code needed to implement the functions will be written. No unnecessary code will be written
• More modular design — As tests are written for micro functions thus creating a clear interface and paving a way for a modular design
• Easier to maintain — As the features are broken down to micro functions it is easier to maintain the code with minimal effect on the other functions
• Easier to refactor — Even if a previous resource who worked on the project has not been involved for a while comes back to make changes it would help in understanding /remembering as there would be tests that would act more as guidelines too
• High test coverage — As there would be tests written to cover the features the test coverage would be higher, as the QA could work on testing other aspects of the program
• Tests document the code — Writing tests also act as guidelines and thus helping in the documentation
• Less debugging — Helps to minimize time wasted on debugging code as the tests would fail in advance and help identify the issue

Disadvantages

• No silver bullet — Tests help to search out bugs, however, they can not discover bugs that you essentially present inside the test code and in execution code.
• Slow process — As you would have to write tests, execute them then write code and execute them again, and wait for the results.
• All the members of a team got to do it — All members of the team need to implement TDD else the coding style/ structure wouldn’t be consistent as well as various time taken by various developers
• Tests got to be maintained when requirements change — Tests need to be changed as requirements change thus facilitating the code for the newer requirements

Reference

https://www.browserstack.com/guide/what-is-test-driven-development

https://www.agilealliance.org/glossary/tdd/

https://en.wikiquote.org/wiki/Kent_Beck

https://arialdomartini.wordpress.com/2012/07/20/you-wont-believe-how-old-tdd-is/

https://blog.usejournal.com/test-driven-development-understanding-the-business-better-9c4cae4cb990

https://www.geeksforgeeks.org/advantages-and-disadvantages-of-test-driven-development-tdd/