1. Course Outline

2. Course Goal Promote best practice and agile software engineering
Processes
Methods
Practices and principles
Tools
Terms used summarized in Appendix A
Practice on a real world project
Room booking system, described in Appendix B
Facilitates learning and understanding
Applying best practices, examples in Appendix C
Applying Patterns, examples in Appendix D
References specified in Appendix E

3. Goals of the course
Experience in working with state-of-the-art methods
Scrum XP
Experience in working with state-of-the-art tools
Visual Studio
NUnit
SubVersion
AnkhSVN (plugin for Visual Studio)
Experience in working in groups
Group dynamics
Planning
Deadlines
Knowledge sharing

4. Timeline of the course First week Introduction Second week
Startup of project
Start of first sprint
Third week
End of first sprint
Mini written exam
Fourth week
Work on second sprint
Fifth week
End of second sprint
Sixth week
Work on third sprint
Seventh week
End of third sprint
Eighth week
Work on fourth sprint
Ninth week
End of fourth sprint
Tenth week
Write report
Present report

5. 3 week goals (will be tested on exam)
Scrum
TDD
What happens if…?
How to do…?
Pros/cons testing before/after
Concepts
Structure
Process
Problem solving
How to work
Roles
Responsibilities
Iterative vs. Water fall
Corresponds to Kniberg, up to p99 and Martin, sections 1 and 2

6. Goals of course Everything from 3 week goals deeper understanding
own opinions
Architecture
Design patterns
Refactoring
Praxis
will not be tested by exam, but by report and by your way of working

7. TDD in practice NUnit tool for executing test suites
produces red, green or yellow status
tells you what went wrong
automatically imports changes made to code
Can be linked to Visual Studio
”add reference” and choose from the list
Imports .dll-files containing test cases
remember: choose ”library” instead of ”executable”
both testfiles and programfiles
F5 executes test suite in NUnit

8. Sprint info A sprint starts with a planning meeting
ends with a sprint demo
Every day
Standup meeting at 8.30 (or other early time)
8 hours of work
No more, no less
No overtime allowed!
Sustainable pace
Long term
Martin is PO and SM
Product Owner
Represents (or is sole) customer
Scrum Master
Makes it work (all practical issues)

9. Testing and Specification
Unit testing
Integration testing
Acceptance testing

10. Principle – Use Executable Specifications
Test Driven Development (TDD)
xUnit
Behaviour Driven Development (BDD)
RSpec
Automatic Acceptance Tests
FIT, Selenium, Sahi, Watir, FITnesse

11. TDD in practice: test syntax
Import library
Informative name for namespace
Declaration that class is test related
Test is the common keyword to use. See documentation of NUnit for other options
Methods should be public void and take no parameters
using NUnit.Framework …
namespace TestXXX {
[TestFixture]
public class TestXXX_X
[Test]
public void Test1() }

12. TDD in practice: test syntax, example
Code to test that creation of a Set is possible
[Test]
public void Existance() {
Set s = new Set();
Assert.IsNotNull(s); }

13. TDD in practice: test syntax, example
Code to test insert-method in a class reprenting a Set
[Test]
public void Insert() {
Set s = new Set();
int anElement = 5;
s.Insert(anElement);
Assert.IsTrue(s.Contains(anElement)); }

14. 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

15. TDD Dojo: 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 dojo
Repeat for a while
Some features first day, continued second day

16. Value of Testing vs Specification
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

17. TDD vs Architecture and Design
Coplien and Martin Debate TDD, CDD and Professionalism
Bob Martin = Robert C. Martin (Uncle Bob)
Jim Coplien = James Coplien

18. 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

19. 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

20. Uncle Bob’s Three Laws of TDD
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
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
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”

21. FIRST Principles
ast
Mind-numbingly fast, as in hundreds or thousands per second.
solated
The test isolates a fault clearly.
epeatable
I can run it repeatedly and it will pass or fail the same way each time.
elf-verifying
The Test is unambiguously pass-fail.
imely
Produced in lockstep with tiny code changes.

22. Red/Green/Refactor Start Write a test for new capability
Refactor as needed (*)
Compile
Run the test
And see it pass
Fix compile
errors
Write the code
Run the test
And see it fail
(*) Always on a green solution 22

23. 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

24. TDD Pattern: Arrange, Act, Assert
William C. Wake's Blog December 2003
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);    } }
Arrange
Act
Assert

25. Unit Testing vs Integration Testing
A test is not a unit test if
It talks to the database
It communicates across the network
It touches the file system
It can't run correctly at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it
It is an integration test
[Feather.UnitTestRulz]

26. Acceptance Testing Requirement documents become outdated
And frequently not updated
Executable specifications are always accurate
Are actually executed

27. 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

28. 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