Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

The Development Cycle 4 Tuesday, September 8, 2009

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Unit Tests 1 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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Examples HelloWorld TicTacToe 18 Tuesday, September 8, 2009

Slide 19

Slide 19 text

Q&A 19 Tuesday, September 8, 2009

Slide 20

Slide 20 text

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