Test Driven Development

Software Engineering, DVGC18

Faculty of Economic Sciences, Communication and IT

2010-09-03

Tobias Pulls and Eivind Nordby

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Principle – Use Executable Specifications

• Test Driven Development (TDD)

• xUnit

• Behaviour Driven Development (BDD)

• RSpec

• Automatic Acceptance Tests

• FIT, Selenium, Sahi, Watir, FITnesse

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD in practice: test syntax

• Create a Test project OR Import

library

• Informative name for namespace

• Declaration that class is test

related

• TestClass is the common keyword

to use. See documentation of

MsTest for other options

• Methods should be public void

and take no parameters

using

Microsoft.VisualStudio.TestTools.UnitT

esting;

…

Namespace XXXTest

{

[TestClass]

public class TestXXX_X

{

[TestMethod]

public void A_A_A()

{

}

}

}

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD in practice: test syntax, example

Code to test that creation of a Set is possible

[TestMethod]

public void Existance()

{

Set s = new Set();

Assert.IsNotNull(s);

}

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD in practice: test syntax, example

Code to test insert-method in a class reprenting a Set

[TestMethod]

public void Insert()

{

Set s = new Set();

int anElement = 5;

s.Insert(anElement);

Assert.IsTrue(s.Contains(anElement));

}

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Dojo info

• Karate or MA

• Dojo is training room

• Everyone takes turns trying out

techniques

• One produces test cases

• Supplier

• would be the aggressor in karate

• Other codes to make test cases

pass

• Receiver

• would be the defender in karate

• Kata

• Practice state of the art

techniques

• Teacher shows

• Student repeats same procedure

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD Kata: A Stack

• Implement a Stack class using TDD

• Demonstration by teacher

• Implement a List class using TDD

• Done by students

• Iterate between teacher and students

• Teaches does one small feature for the stack, students do the same feature for

the list as a kata

• Two students per computer

• Repeat for a while

• Some features first day, continued second day

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Value of Testing vs Specification

• Testing• Testing is by samples

• Testing can only prove a system to be wrong

• Test cases may be executed

• Specification• Specification describes general case

• Specification describes what is right

• Specifications may often be executed

• Imperfect tests, run frequently, are much better than perfect tests that are never written at all

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD vs Architecture and Design

• Coplien and Martin Debate TDD, CDD and Professionalism

• Bob Martin = Robert C. Martin (Uncle Bob)

• Jim Coplien = James Coplien

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Testing vs. xDD

• Traditional Unit, Integration, System and Acceptance Testing are done after

the fact

• Code, then write test

• Ideally, system and acceptance tests are written before design and coding

• xDD (TDD, BDD) ”tests” are written before design and implementation

• They are ”driving” the development

• Also called Example Driven Development

• No development is done unless there is a failing test

• TDD tests are

• As much about exploring the design of the system

• As they are about bug catching

• TDD is how I do it, not what I do

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Tim Ottingers TDD in Three Index Cards

• Three Index Cards To Easily Remember The Essence Of Test-Driven Development

• Card #1. Uncle Bob’s Three Laws

• Fail first, Only enough test to fail, Only enough solution to pass

• Card #2: FIRST Principles

• Fast, Isolated, Repeatable, Self-verifying, Timely

• Card #3: Core of TDD

• Red, Green, Refactor

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Uncle Bob’s Three Laws of TDD

1. Do not write a line of production code until you have written a failing unit test

• No production code can be written until there is a failing unit test

2. Do not write more of a unit test than is sufficient to fail, and not compiling is failing

• So you cannot write very much of the unit test before you write production code

3. Do not write more production code than is sufficient to pass the test

• You cannot write a little bit of unit test and then run off and write production code.

• These three laws lock you into a cycle that is perhaps 30 seconds long

• You are actually writing unit tests and production code concurrently, with the tests perhaps 30 seconds to a minute ahead

• ”That is my definition of TDD”

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

FIRST Principles

F ast

Mind-numbingly fast, as in hundreds or thousands per second.

I solated

The test isolates a fault clearly.

R epeatable

I can run it repeatedly and it will pass or fail the same way each time.

S elf-verifying

The Test is unambiguously pass-fail.

T imely

Produced in lockstep with tiny code changes.

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Red/Green/Refactor

Write a test for

new capability

Start

Compile

Fix compile

errors

Run the test

And see it fail

Write the code

Refactor as needed (*)

Run the test

And see it pass

(*) Always on a green solution

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD Pattern: Red, Green, Refactor

• Test Driven Development: By Example, Kent Beck, Addison-Wesley

Longman, 2002

• Simple example: Push for stack

• Create test case: testPush

• Compile error: no such method exists

• Create push method (stub)

• No compile error, but test case does not pass

• Implement push to satisfy test

• Test passes

• Refactor (if needed)

• Always refactor on a fully working (green) system

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

TDD Pattern: Arrange, Act, Assert

import junit.framework.*;

public void TestClass extends TestCase

{

public void testSomething()

{

Stack stack = new Stack();

stack.push("Test string");

String result = stack.pop().toString();

assertEquals("Expected last value pushed", "Test string",

result);

}

}

Act

Arrange

Assert

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Unit Testing vs Integration Testing

• A test is not a unit test if

1. It talks to the database

2. It communicates across the network

3. It touches the file system

4. It can't run correctly at the same time as any of your other unit tests

5. You have to do special things to your environment (such as editing

config files) to run it

– It is an integration test

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Acceptance Testing

• Requirement documents become outdated

• And frequently not updated

• Executable specifications are always accurate

• Are actually executed

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Frameworks for Automatic Acceptance Testing

• Fit

• Executes HTML tables with matching input and output

• FitNesse

• Front-end to Fit and wiki to organize tests

• RSpec (for Ruby)

• Write tests in plain english

• JSpec

• RSpec for Java

• All do Specification by Examples

KARLSTAD UNIVERSITY

COMPUTER SCIENCE

Eivind Nordby

Software Engineering, DVGC18

Working with Acceptance Testing

• End user / product owner specify examples

• Examples are encoded in framework

• Selected examples drive development top-down

• Normally complemented by unit tests bottom-up