Test Driven Development(TDD)
INTRODUCTION
Test Driven Development(TDD) is a software development process developed and discovered by Kent Beck. It is a technique where test code is written before production code. It is a technique that is used for designing as well as testing software. Basically, TDD is a process that turns requirements into very specific test cases. It is one of the core principles of extreme programming. It is referred to as test driven design. Unit tests and Refactoring are considered as components of TDD. It is not a one way or linear process.
To summarize Test Driven Development(TDD) is a proven technique to ensure effective unit testing. It consists of short development iterations. TDD is nothing but a technique of TFD (Test First Development) and Refactoring together. TDD promotes improved quality because extensive verification is performed.
TDD is a technique that discovers the mistakes upfront and prevents code with too many defects. The main benefit of using TDD is that one can write a high level of quality code much faster than without TDD because modifying the existing code with TDD is easy.
IMPORTANT PRINCIPLES OF TDD
Important principles of TDD are:
- Write tests, then the code
- Write a code only when test fails
- write the code to make tests pass, Eliminate duplication
WHY TEST-DRIVEN DEVELOPMENT IS?
There are many constant changes in business requirements for software applications. Thus, making modification in a traditionally developed software application seems to be difficult. Because of this many organizations hesitate to make changes, thus affecting their overall success. TDD is thus indeed a solution to this because it makes developers easier to make the required modifications to the application without affecting the operations of the application.
The core objective behind using TDD is to implement smaller test cycles and achieve more agility in the process. With TDD, you start by creating the test cases for a new feature, write code required to pass the test, after that refactor the code to increase its sustainability. In TDD, automated tests are written before writing the code which helps to get fast confirmation on whether the code works as expected or not. TDD immersed as a reaction to waterfall development. It’s an incremental and evolutionary design technique.
STAGES OF TDD
There are three stages of TDD, see the details below:
Red Stage
Red stage consists of tests creation in which initially tests fail as code is not written or features may not be implemented. Therefore, any failure in this stage is not considered as a bug or defect.
Green Stage
Green stage consists of writing code in order to make the test pass. For writing code practices like “Keep it Simple (KISS) are recommended. The code written in this stage may not be of high quality and coding values are hard coded, but that can be refactored in the next stage.
Refactor Stage
Refractor stage consists of improving the quality of code without changing the actual behavior. While refactoring, duplicate code is removed, and any hardcoded data is parameterized in order to match the actual requirements. Any bad coding practices used are also cleaned up improving Readability, performance and maintainability. At the end of the refactoring process, the Existing test cases should still pass to ensure that the functionality has not been broken.
It is called Red/Green Refactor because the unit testing framework displays a red bar for failing and green bar for passing tests. TDD tests are executed in less than 10 mins.
BENEFITS OF TDD
- TDD keeps the code clear and simple and improves the quality of code. It Ensures that the written code is covered by at least one test, thus increasing the level of confidence in the code.
- TDD reduces the debugging time and Eliminates duplication of code.
- TDD helps in complete understanding of requirements and provides the ability to modify the application with the changing business requirements.
DRAWBACKS OF TDD
- Main drawback of using TDD is that Database and external files are not tested.
- TDD seems to be Difficult for GUI (Graphical User Interfaces) & relational databases.
- TDD requires additional time to write and maintain test cases.
- TDD Tests can sometimes be incorrectly formulated or applied as a result unit tests do not perform as expected in real domain and Efforts are required to maintain test suites
LEVELS OF TDD
There are 2 types of TDD:
- ATDD (Acceptance TDD)
- TDD (Developer TDD)
Acceptance TDD
Acceptance TDD is the collaborative practice and advanced form of TDD. In this automated acceptance criteria are defined early in the development process. It focuses on external quality of software.
In scrum with the project manager to find out the acceptance criteria to achieve the requirements that the user stories represent. ATDD shows a clear picture of how the product will look.
Developers TDD
Developers TDD focus on specifying complete plans on a JIT (just in time) basis. In developer TDD, a simple developer test frequently referred to as unit test is written and then just enough production code to pass that test is written.
TOOLS FOR TDD AND ATDD
Tools for TDD
- .Net — Nunit
- Java — Junit
- C++ — gunit
- Python — Pyunit
Tools for ATDD
- FitNesse
- Selenium
- Sahi
- Frankenstein
DIFFERENCE BETWEEN NORMAL AND TDD APPROACH TO DEVELOP A SOFTWARE:
Normal Approach
Steps:
- Write a code (logic) and compile it.
- Write unit tests to test the code.
- Run the unit tests to check if the logic is working or not.
TDD Approach
Steps:
- Write unit tests.
- Execute the tests (the test case will fail as there is no code written).
- Write code to make sure the unit test compiles.
- Execute the unit test and see if it passes or fails.
- If it passes, then move on to the next unit test, else refactor and then execute.
DIFFERENCE BETWEEN NORMAL AND TDD APPROACH FOR TESTING A SOFTWARE
Normal Approach
- Focus is on test case design
- Generate the code and then write test cases based on that code
TDD Approach
- More focus is on production code
- Code is written for already created test cases.
HOW TDD HELPS TO AVOID SCOPE CREEP AND PREVENT BUGS
Scope creep can happen due to several reasons like lack of documentation, misinterpretation of project requirements, ineffective distribution of tasks etc.
TDD environment developers write unit tests to test a feature to be implemented. Therefore, avoids redundant code that wasn’t specified in the project requirement.
TDD is a unique agile approach which when followed properly results into 100% test coverage. TDD developers focus on preventing bugs rather than removing it later.
ROLE OF QA IN TDD
In TDD, developers use test cases to develop their code and execute test cases respectively. So, in TDD major dependency is on test cases. So, test cases with good coverage of requirements are more important for making TDD successful. It is an overall observation that QAs know the system much better than a developer as they test the system End-to-End. Therefore, it is required to involve the QA team from the beginning of the project. QA & developer should work together to create test cases. It helps developers to design better unit level test cases & QA can set up acceptance test cases that are at a higher level than unit test cases.
Tester’s knowledge of the system and the developer’s technical knowledge accomplished each other to help adding duplicate and invalid tests
REFERENCES:
https://docplayer.net/15430061-Test-driven-development.html
http://www.agiledata.org/essays/tdd.html
Software DevelopmentPrint
