What is Test Driven Development (TDD)?
Test Driven Development (TDD) is a software development approach where a test is written before the code is written. Once the new code passes the test, it will be converted to an acceptable standard.
TDD ensures that the source code is thoroughly tested and results in modularized, flexible and extensible code. It focuses on writing only the code necessary to pass tests, which makes the design simple and clear.
TDD allows the programmer to take small steps in writing software. The test is written before testing functionality and ensures that the application is suitable for testability. Testing of a small amount of code is done to find bugs that appear in the code being tested.
Then the functionality is implemented. This is known as the "red-green refactor," where red means failed and green indicates a pass. These steps are then repeated. A programmer's first goal is to focus on the task and hand it off.
The different steps of a test-driven development cycle are:
Adding a Test: Every new feature in TDD begins with a test that, if implemented, must fail before any features are implemented. The basic requirement for writing a test prior to feature implementation is a clear understanding of the requirement by the developer. This is achieved through user stories and use cases. Therefore, a developer understands the requirement before writing the program code.
Run all tests and see if the new code fails: this will ensure the correct working of the test cables and the new test will not accidentally run without new code. This step also tests the test, eliminating the possibility that the new test will always pass.
Writing code: The next step that follows is writing code that will clear the test. The new code is not perfect, but will be modified later according to requirements. It is only intended for testing and does not include any other functionality.
Run automated tests: If each test case passed the test without any problems, it means that the code meets all the required specifications. The last step of the cycle can thus be started.
Refactor Code: This is similar to removing duplicates. Refactoring does not damage existing functions and helps avoid duplication between production and test code. The code is now cleaned up as needed.
Repeat: The cycle is repeated with a new test as in the previous cases. The basic requirement is that the size of the steps should be small, with about 1 to 10 changes between each test run. If new code is not enough for a new test, the programmer should do additional debugging. The continuous integration offers resettable test points.
English 
German 