Test Driven Development Workshop Mike Scott Test Management Summit, January 2010 SQS Group Limited
Why Test? Code that isn t tested doesn t work. This seems to be the safe assumption. Kent Beck The Father of XP
Test? Driven Development BDD TDD ATDD DDD UTDD FDD
Tests As Specifications One of the most effective ways of specifying something is to describe (in detail) how you would accept it if someone gave it to you. Bill Hetzel
What is TDD? Test Driven Development Traditional Process Document a requirement Specify a design solution for the requirement Implement the design in code Test that the coded solution satisfies the requirement Test-Driven Process Document a requirement Design a solution by documenting example (test) cases Implement the design by coding to make the example cases true
TDD Methodology Da rulez! Three simple rules: 1. Write new code only to make a failing test pass 2. Don t write any more of a test than is needed to fail 3. Don t write any more code than is needed to pass the test
Tests and Specifications Brian Marick
Example: Test-Driven Hello World Step 1: Write the Acceptance Test Programmer says: I want to Test-Drive a Hello World program To start this new requirement in a test-driven way Start by expressing the requirement as a simple test table Remember, the program itself does not yet exist We are setting the bar The Acceptance Test Test Greeting : When asked to Say Hello, Expect return of Hello World Test Greeting Say Hello? Hello World
Example: Test-Driven Hello World Step 2: Run the Test There is no implementation to make the test case pass! Performing this test results in failure Test Greeting Say Hello? Hello World
Example: Test-Driven Hello World Oh no! Chuck found our test and took it to a Marketing meeting! The global scope of the greeting is really positive! Yes, but we should leverage a dynamic customer-centric paradigm to synergise our market reach with a directly targeted focus, creating vast greeting opportunities! Hello World Chuck Awesome, Chuck. The café lattés are on me!
Example: Test-Driven Hello World Step 3: Write the implementation code to make the test pass Fix the failing test using the simplest implementation that passes This might not be the final implementation But as long as all tests pass, it is sufficient (We will add more tests to prove any limitations) Test Greeting Say Hello? Hello World
Example: Hello World Iteration 2 Requirements have changed: Modify the test The customer expresses the new required logic in a readable (and testable) way that is meaningful to them Chuck changes the test table New parameter called Name Change the returned text Running this test will cause it to fail The implementation cannot yet take the Name parameter It still returns Hello World only Greeting Test Name Say Hello? Chuck Hello Chuck Suzie Hello Suzie
Example: Hello World Iteration 2 Hello Chuck Programmer says: Now I need to fix the Failing tests When we construct a Greeting with a name return a message saying Hello to that name Quickly gets us a passing test public class Greeting { private string name; public Greeting(string name) { this.name = name; } public string SayHello() { return "Hello " + name; } } Greeting Test Name Say Hello? Chuck Hello Chuck Suzie Hello Suzie
Exercise Myers Triangle Problem The requirement A function that returns what type of triangle results from the measurements of three sides Equilateral, Isosceles, Scalene, Invalid (anything else?) The Exercise Draw up a table with columns for the inputs and outputs required for this function Create a set of examples that demonstrate how it should work How many test cases could you create? How many do you think you actually need?
TDD Methodology From simple rules, many beneficial results Many Interesting Implications Details of user requirements are expressed as tests Tests act as both specification and verification Tests are closely associated with requirements Test coverage is constantly high All tests can be used for regression Testing time is factored into development time Quality can remain high, even as functionality evolves
What are the technical requirements for TDD? Project Automation Automatically build from latest source code (Continuous Integration) Automatically run one or more test suites (Continuous Quality) Unit Test Framework Automated white-box tests written by developers Acceptance Test Framework Automated black-box tests written by testers / analysts / customer Other Automated Tests GUI tests, non-functional tests, static analysis... Code Coverage Analysis How much of the code base is being tested by our suites? SQS Group Limited Testify 16
The Balloon pattern Start Valid, but Empty An empty balloon is still a balloon Complete the form or structure of a solution, before adding function Rubber before Air Don t deliver functionality that cannot be tested Delaying testing is just incurring quality debt Use Iteration Zero Produce installable / deployable software 100% of automated tests pass, with high test coverage Functionality is trivial (at best) SQS Group Limited Testify 17
Thanks for your attention Mike.Scott@sqs-uk.com 7 Moorgate London, EC2R 6AF, United Kingdom Tel.: +44 (0) 20 7448 4620 Fax: +44 (0) 20 7448 4651 E-Mail: info@sqs-uk.com Internet: www.sqs-uk.com www.sqs-group.com
Useful? Web Links FIT & FitNesse www.fitnesse.org Cucumber cukes.info/ Concordion www.concordion.org jbehave jbehave.org/ NUnit www.nunit.org Other xunit implementations www.xprogramming.com Selenium www.openqa.org/selenium Robot Framework code.google.com/p/robotframework/ Testify http://code.google.com/p/testifywizard/ Open Source test tools www.opensourcetesting.org Gojko Adzic http://gojko.net Brian Marick s Agile Testing www.testing.com/agile Agile Alliance www.agilealliance.org Ward Cunningham s Wiki c2.com/cgi/wiki Unit Testing Patterns xunitpatterns.com Michael Feathers on Legacy Code etc. www.objectmentor.com/resources/publishedarticles.html