Test Driven Development - DPUG September 2009

1. TEST DRIVEN DEVELOPMENT
DPUG - 09/08/2009 - Jason Ragsdale
1

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

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

4. The Development Cycle
4

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

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

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

8. Limitations
Badly written tests, are expensive to maintain.
8

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

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

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

12. Limitations
The high number of passing unit tests may bring a false sense of security
12

13. Unit Tests
A unit is the smallest testable part of an application.
13

14. Unit Tests
1 <?php
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

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

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

17. Ok Now What?
No enhancements without defined requirements.
Can not write tests for items without requirements.
17

18. Examples
HelloWorld
TicTacToe
18

19. Q&A
19

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