Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Test Driven Development

Jason Ragsdale
September 08, 2009

Test Driven Development

Jason Ragsdale

September 08, 2009
Tweet

More Decks by Jason Ragsdale

Other Decks in Technology

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