Test Driven Development Want to go for a drive? Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Introduction Attributed to Kent Beck Claims he rediscovered it Popularized in a 2002 book This method is based on the notion of unit tests being primary We write unit tests first Then generate just enough code to pass the tests Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Quote If it’s worth building, it’s worth testing If it’s not worth testing, why are you wasting your time working on it? Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill The Cycle TDD uses the following set of steps Repeat Add a test Run all tests Write or update the code, possibly with a refactor step Run tests Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Flow Graph http://agiledata.org/essays/tdd.html Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Add a test We first create a unit test for a new feature The test defines the feature or enhancement that we need Requires understanding of the requirements Based on use-cases or user stories This precedes the creation of any code Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Run Tests Several things need to be confirmed here Initial runs we confirm that the unit test system works In all runs we find out far we missed the mark If a new test does not create any new errors Either poor test or we have discovered capabilities that already existed and no new code is needed Usually we see the lack of capability Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Write/Change Code The first time a test fails we usually create a new class/method/function We write the minimum amount of code to pass the test No guessing as to what will be needed in the future We loop back through tests until we pass This is often the stage where refactoring also occurs Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Run Tests Again When all the tests have been passed we ask the question Have we implemented all that we need? Has every user story been implemented? If so the program is done otherwise we create new tests for new use cases/user stories Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Two Levels of Tests Acceptance tests cover the entire system Unit tests cover a single class or function The difference is largely one of scope The upper most class is usually the program It’s unit test is an acceptance test Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Random Thoughts The unit tests are automated in some fashion Passing the unit test that we are shooting for and causing another one to fail is unacceptable One study showed that developers using TDD on new projects seldom needed to use a debugger Higher level unit tests tended to generate false errors Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill TDD and XP Test Driven Development is at the heart of eXtreme Programming TDD is a subset of XP XP prescribes many other practices that are not TDD TDD may also be used in many other agile processes, such as Scrum Copyright © 2015-2017 by Curt Hill

Traditional testing and TDD Traditionally developers use tests to find defects in the code TDD does this as well Traditional testing is applied after the code is written TDD is before TDD also uses the tests as a documentation of the specfications Some refer to the TDD as a specification technique with the side effect of better testing of the code Copyright © 2015-2017 by Curt Hill

Copyright © 2015-2017 by Curt Hill Finally The key to TDD is to convert use cases or user stories directly into tests Then generate the code to pass the tests The tests are both specifications and tests An executable specification of sorts Finally for now Copyright © 2015-2017 by Curt Hill