Test Driven Development

Transcript

1. TEST DRIVEN DEVELOPMENT
   DPUG - 09/08/2009 - Jason Ragsdale
   1
   Tuesday, September 8, 2009
   

   View Slide

2. What is TDD?
   Test-driven development (TDD) is a software development 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
   

   View Slide

3. The Three Laws of TDD
   1. Don’t write any code 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
   

   View Slide

4. The Development Cycle
   4
   Tuesday, September 8, 2009
   

   View Slide

5. Benefits
   The first goal is to make the test pass.
   Subsequent users have a greater level of trust in the code.
   Executable Documentation.
   5
   Tuesday, September 8, 2009
   

   View Slide

6. Limitations
   Some Code is Hard to Test.
   Don’t Test That Code, Minimize that Code.
   Put the important code in a library and test that code.
   6
   Tuesday, September 8, 2009
   

   View Slide

7. Limitations
   Management support is essential.
   Without the organization support, that TDD is going to improve the
   product.
   Management will feel that time spent writing tests is wasted.
   7
   Tuesday, September 8, 2009
   

   View Slide

8. Limitations
   Badly written tests, are expensive to maintain.
   8
   Tuesday, September 8, 2009
   

   View Slide

9. Limitations
   The level of coverage and testing detail achieved during 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
   

   View Slide

10. Limitations
    Unexpected gaps in test coverage may exist or occur 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
    

    View Slide

11. Limitations
    Unit tests created in a TDD environment are typically 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
    

    View Slide

12. Limitations
    The high number of passing unit tests may bring a false sense of security
    12
    Tuesday, September 8, 2009
    

    View Slide

13. Unit Tests
    A unit is the smallest testable part of an application.
    13
    Tuesday, September 8, 2009
    

    View Slide

14. Unit Tests
    1 2 class WhenTestingAdder {
    3 public function shouldAddValues() {
    4 $adder = new Adder();
    5 $this->assertEquals(2, $adder->add(1, 1));
    6 $this->assertEquals(3, $adder->add(1, 2));
    7 $this->assertEquals(4, $adder->add(2, 2));
    8 $this->assertEquals(0, $adder->add(0, 0));
    9 $this->assertEquals(-3, $adder->add(-1, -2));
    10 $this->assertEquals(0, $adder->add(-1, 1));
    11 $this->assertEquals(2222, $adder->add(1234, 988));
    12 }
    13 }
    14 ?>
    14
    Tuesday, September 8, 2009
    

    View Slide

15. Integration Tests
    Individual software modules are combined and tested as a group.
    It occurs after unit testing and before system testing.
    15
    Tuesday, September 8, 2009
    

    View Slide

16. System Tests
    Testing conducted on a complete, integrated system to 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
    

    View Slide

17. Ok Now What?
    No enhancements without defined requirements.
    Can not write tests for items without requirements.
    17
    Tuesday, September 8, 2009
    

    View Slide

18. Examples
    HelloWorld
    TicTacToe
    18
    Tuesday, September 8, 2009
    

    View Slide

19. Q&A
    19
    Tuesday, September 8, 2009
    

    View Slide

20. Links
    PHPUnit
    http://www.phpunit.de/
    Three Rules of TDD
    http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
    TDD - 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
    

    View Slide