Test-Driven Development

(1)

Test-Driven Development

An Introduction Mattias Ståhlberg

(2)

Debugging

sucks.

(3)

What is a Unit Test?

 _{A unit is a class or a set of related functions}

Smallest part that makes sense to test

 _{Tests that the unit does what the programmer intended}  _{Tests the unit’s public interface}

 _{Written contract that the production code must satisfy}  _{Requires an automatic unit testing framework}

(5)

Java Example with JUnit

@Test

public void shouldCalculateAverageSpeed() { Track track = new Track();

track.addPoint(0, 0, 0); track.addPoint(0, 1, 1); track.addPoint(1, 1, 2); track.addPoint(1, 0, 3); track.addPoint(0, 0, 4); assertEquals(1, track.averageSpeed()); } @Test(expected=ArithmeticException.class)

public void averageSpeedShouldThrowExceptionOnZeroDistance() { Track track = new Track();

(6)

Advantages of Unit-Tested Code

 _{Gives courage to modify and improve (refactor) the}

code

 _{Knowledge that the code works}

 _{Problems solved early in the development phase}  _{Documents the code}

 _{Little or no need for debugging}

 _{Reduced need for costly manual testing}  _{Saves time and money}

(7)

Properties of Good Unit Tests

 _{Descriptive name}  _Readable  _Focused  _Isolated  _Automatic  _Repeatable  _Fast

(8)

What is Test-Driven Development?

 _{Test-driven is more about design than about testing}

A design method that renders clean, well-tested code

 _{Short iterations where unit tests, either for}

(10)

What is Test-Driven Development?

(contd.)

 _{Can also be applied to other types of tests (e.g.}

acceptance tests)

 _{Does not imply “no formal testing”}  _{Kent Beck:}

“Never write a single line of code unless you have a failing automated test”

(11)

Development Cycle

1. Create a new automatic test case

2. Run all tests and watch the new one fail

3. Write production code to make the test pass

4. Run all tests and watch them pass

5. Refactor the code, e.g. eliminate duplicated code

6. Start over

(12)

Advantages of Test-Driven

Development

 _{Interfaces are tried before they exist  more mature}

interfaces

 _{More and better tests  improved quality}

 _{Design and code evolved in small steps  less risk, less}

integration problems

 _{Less risk to develop functionality “that might be}

needed”

 _{Less risk to skip testing when time is short}  _{Addictive, stimulating, and great fun}

(13)

Test-Driven Bug Fixing

1. Create an automatic test that indicates the existence of the bug

2. Locate the bug

3. Fix the bug

 _{Ensures that the automatic tests will detect the problem}

(14)

Live Demonstration

 _{TDD using Eclipse and JUnit}

http://www.eclipse.org

(16)

Writing testable code

 _{Use dependency injection}  _{Inject interfaces}

 _{Favor object composition over class inheritance}

Impossible to chose different class hierarchy at test-time but easy to chose different object composition

 _{Favor polymorphism over conditional statements}

Leads to smaller and more focused classes, which are easier to test

(18)

Writing testable code (contd.)

 _{Avoid global state and singletons}

Cannot be replaced at test-time

If you really have to have a singleton: Wrap it in a simple adapter

 _{Avoid non-private static method calls}

Cannot be replaced at test-time

Can be wrapped in a simple adapter

 _{Strive for small and focused classes with clear}

(19)

Google's guide to testable code

http://misko.hevery.com/code-reviewers-guide/

 _{Flaw #1: Constructor does Real Work}  _{Flaw #2: Digging into Collaborators}

 _{Flaw #3: Brittle Global State & Singletons}  _{Flaw #4: Class Does Too Much}

(20)

Definition of Continuous Integration

 _{“A fully automated and reproducible build, including}

testing, that runs many times a day” Martin Fowler (September 2000)

 _{“A software engineering practice in which isolated}

changes are immediately tested and reported on when they are added to a larger code base.”

(22)

Continuous Integration – Benefits

 _{Allows each developer to integrate daily thus reducing}

integration problems

 _{Provides rapid feedback on the “health” of the software}  _{If a defect is introduced into the code base, it can be}

identified and corrected as soon as possible

(23)

(24)

Try it out!

 _{Download Hudson from}_{www.hudson-ci.org}

(25)

Unit testing

 _{Gives courage to refactor and improve}  _{Eliminates problems early}

 _{Requires discipline}

(29)