Content deleted Content added
added a new external link that is relevant and interesting |
Added additional content to Limitations and new section TDD Cycle |
||
Line 4:
In order for TDD to work in practice, the system must be flexible enough to allow for [[automated testing]] of code. The system must also have testcases in place before TDD can be used. These tests must also be simple enough to return a simple true or false evaluation of correctness. These properties allow for rapid feedback of correctness and design.
== Test-Driven Development Cycle ==
It first begins with writing a test. In order to write a test, the specification and requirements must be clearly understood. The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through it's interfaces. This is the design driven part of TDD. The next step is to run the automated testcases and observe if they pass or fail. If they pass, the programmer can be guaranteed that the code meets the testcases written. If there are failures, the code did not meet the testcases. The final step is the [[refactoring]] step and any code clean-up necessary will occur here. The testcases are then re-run and observed. The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.
== Differing styles ==
There are various ways one can go about using TDD and the most common one is based on KISS (Keep it simple stupid) or YAGNI (You aren't going to need it). This style focuses on writing code anyway necessary in order to pass the tests. Design and propery principles are cast aside in the name of simplicity and speed. Therefore, any rule can be violated as long as the tests will pass. This can be unsettling for many at first but it will allow the programmer to focus only on what is important. However, the programmer must pay a bigger fee in the [[refactoring step]] of the cycle since the code must be cleaned up to a reasonable level at this point before the cycle can restart.
Another variation of TDD requires the programmer to first fail the testcases. The idea is to ensure that the testcase really works can will catch an error. Once this is shown, the normal cycle will commence. This is one of the more popular variations and has been coined the "TDD Mantra", known as red/green/refactor where red means fail and green is pass.
== Benefits ==
Line 10 ⟶ 20:
The power of TDD offers is the ability to take small steps when required. It allows a programmer to focus on the task at hand and often the first goal is to make the test pass. Exceptional cases and error handling are not considered initially. These extraneous circumstances are implemented after the main functionality has been achieved.
As a nice side-effect of TDD, the system will also gain a large catalog of regression tests which can fully test the system at a moments notice.
== Limitations ==
Line 19 ⟶ 31:
* Database Schema
* Compilers and Interpreters from BNF to production quality implementation
It is also important to note that Test-driven Development only proves correctness of design and functionality according to the testcases written. An incorrect testcase that does not meet the specifications will produce incorrect code. Therefore, the emphasis on correctness and design has shifted to writing testcases since they are the drivers.
----
| |||