technique that relies on the repetition of a very short development cycle: 1. First write a failing automated test case that defines a desired improvement or new function 2. Then produce code to pass that test 3. Finally refactor the new code to acceptable standards. 2 Tuesday, September 8, 2009
unless it is to make a failing test pass. 2. Don’t write any more of a unit test than is sufficient to fail. 3. Don’t write more code than is sufficient to pass the one failing unit test. 3 Tuesday, September 8, 2009
repeated TDD cycles cannot easily be re-created at a later date. Therefore these original tests become increasingly precious as time goes by. If a poor architecture, a poor design or a poor testing strategy leads to a late change that makes dozens of existing tests fail, it is important that they are individually fixed. Merely deleting, disabling or rashly altering them can lead to un- detectable holes in the test coverage. 9 Tuesday, September 8, 2009
for a number of reasons. One or more developers in a team was not so committed to the TDD strategy and did not write tests properly. Some sets of tests have been invalidated, deleted or disabled accidentally or on purpose during later work. Alterations may be made that result in no test failures when in fact bugs are being introduced and remaining undetected. 10 Tuesday, September 8, 2009
created by the developer who will also write the code that is being tested. The tests may therefore share the same blind spots with the code. 11 Tuesday, September 8, 2009
evaluate the system’s compliance with its specified requirements. Falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. 16 Tuesday, September 8, 2009
Wikipedia http://en.wikipedia.org/wiki/Test-driven_development BDD - Wikipedia http://en.wikipedia.org/wiki/Behavior_Driven_Development http://www.phpspec.org/ 20 Tuesday, September 8, 2009