Extreme programming practices: Difference between revisions

Revision as of 11:55, 7 September 2017

Revision as of 12:09, 7 September 2017

Line 114:

=== Test driven development ===

[[Unit testing|Unit tests]] are automated tests that test the functionality of pieces of the code (e.g. classes, methods). Within XP, unit tests are written before the eventual code is coded. This approach is intended to stimulate the programmer to think about conditions in which his or her code could fail. XP says that the programmer is finished with a certain piece of code when he or she cannot come up with any further conditions under which the code may fail. For a more intense version of this process, see Uncle Bob's Three Rules of TDD.

Test driven development proceeds by quickly cycling through the following steps, with each step taking minutes at most, preferably much less. Since each user story will usually require one to two days of work, a very large number of such cycles will be necessary per story.

* Write [[unit test]]: The programmers write a minimal test that should break the codefail because the functionality hasn't been fully implemented in the production code.

* Watch the new test fail: The programmers verify the codetest does indeed fail. While it may seem like a waste of time, this step is critical because it verifies that your belief about the teststate of the production code it correct. If itthe test does not fail, the programmers should determine ifwhether there is a bug in the test code, or that the production code does indeed support the functionality described by the new test.

* Write code: The programmers write thejust minimalenough amount ofproduction code to passso the new test will pass.

* Run test: The unit tests are runexecuted to verify that the new production code passes the new test, and that no other tests are failing.

* [[Code refactoring|Refactor]]: Remove any [[code smells]] from both the production and test code.