Test Driven Development - kau.se · • Behaviour Driven Development (BDD) • RSpec • Automatic...
Transcript of Test Driven Development - kau.se · • Behaviour Driven Development (BDD) • RSpec • Automatic...
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