Course Outline

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

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

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

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

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

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

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)

Testing and Specification Unit testing Integration testing Acceptance testing

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

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() }

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); }

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)); }

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

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

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

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

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

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

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”

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.

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

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

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

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]

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

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

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