1Test Driven DevelopmentAn IntroductionBy Robert Stehwien2Test Driven Development• Introduction• How• Why• Tips• Credits• Katas3What is Test Driven Development?• An iterative technique to develop software• As much (or more) about design as testing– Encourages design from API user’s point of view– Encourages testing classes in isolation– Produces loosely-coupled, highly-cohesive systems• As much (or more) about documentation as testing• Must be learned and practiced– If it feels natural at first, you’re probably doing it wrong24Automated Tests• Unit tests– Tests that show the programmer that the code does what is expected– Specifies what the code must do– Provide examples of how to use the code (documentation)– All tests are run every few minutes, with every change• Acceptance tests– Tests that show the stake holders that the code delivers the feature– All tests are run at least daily• All tests are Automated, you run them with every change5Uses of Automated Tests• Living documentation of design– The tests fail if the design changes• Example of how to use an interface• Watching for bugs– Once a test passes, it is re-run with every change– Broken tests are not tolerated– Side affect defects are detected immediately– Assumptions are continually checked• Improving the design of code6Test Driven Development• Introduction• How• Why• Tips• Credits• Katas37Test Driven Development Cycle1. Add a test2. Compile3. Fix compile errors4. Run all tests and see the new one fail5. Write some code6. Run the tests and see them succeed7. Refactor code• Many small steps toward a goal often leads to a different or better place8Do the Simplest Thing• Assume simplicity– Consider the simplest thing that could possibly work– Iterate to the needed solution– YAGNI• When coding:– Simple, clear, and maintainable– Build the simplest possible code that will pass the tests – Refactor the code to• Have the simplest design possible• As clear and communicative as possible– Eliminate duplication9The Rules of Simple DesignIN PRIORITY ORDER!1. The code passes all tests2. There is no duplication3. The code expresses the programmer’s intention4. Using the smallest number of classes and methodsHigher priority rules must be satisfied first410What is Tested?• Every class (module) has one or more unit tests• Test everything that can possibly break• If it can’t break, don’t test it– Always a judgment callint Student::GetName(){return name;}StudentStudentTest11Focus on Interface• The test treats the object being tested like black box• Encourages design to be done from a client point of view– The test is a user of the API• You confront interface design issues– What are the parameters?– What is the return type?– What is the behavior?– Who controls object lifetime?• Looks similar to Design by Contract12Testing Frameworks• Tests must be automated– Otherwise they won’t be run• Most OO languages have a testing framework, xUnit– JUnit, CppUnit(Lite), PyUnit, NUnit, VBUnit, Ruby’s Test::Unit– A simple tool– Collects, organizes and automatically calls your test code• Graphical test runner– Green bar makes you feel good• Could be added to build environment513JUnit Demo• Wherein the instructor shows you how to make a simple unit test framework for a class14Test Driven Development• Introduction• How• Why• Tips• Credits• Katas15Objections Heard• “I know how to just write the code, but I don’t know how to test it.”• “We have to write twice as much code”• “I have to debug twice as much code.”• “We have a testing department.”• “I can test my code after I write it.”• “That might work on easy software but our problem is really tough”• “You need the target hardware”616Design Impacts• Test-first design promotes testing a class in isolation– It must be decoupled from other classes• Produces loosely coupled, highly cohesive systems– The hallmark of a good design– Object Oriented Design Principles and Programming Languages help17Productivity and Predictability• Defects kill predictability:– Cost of fixing is not predictable– When they materialize is not predictable• Test-driven is predictable:– Working at a steady pace– Results in fewer bugs– More productive than “debug-later programming”• Test-driven programmers rarely need the debugger18Sufficiency• Produces higher quality code– Tests evolve as your understanding increases– Code evolves to satisfy the tests• Provides only enough code to meet the tests• Provides a high level of comfort that allows refactoring719Reward and Feedback• Frequent feedback• Make something work every programming session• Check in functioning code every time20Test Driven Development• Introduction• How• Why• Tips• Credits• Katas21Learning Test-First Design• A skill which must be practiced– Initially awkward• Requires discipline– Peer pressure– “I know how to write the class, but I don’t know how to test it”• It's an addiction rather than discipline– Kent Beck – Author of • Extreme Programming Explained• Test Driven Development822You Aren’t Going to Need It (YAGNI)• Temptation to add methods or infrastructure– Fear that you might need it later• Resist the temptation• Let the user stories force you to add it later– If they do, it won’t be that much worse– If they don’t, you’ve saved time, effort, and complexity• Generality is paid for when the need is proven23Leading The Witness• Doesn’t eliminate all need for design– Combining design-up-front with TDD– Architecture design important• Writing tests that move toward design• Design patterns• Refactoring toward patterns• Knowing when to stop– When “good enough”24Toss It• One of the best things a programmer can do– Throw out code– Throw out a design• If you struggle with something all day– Pitch it– It’s only one day’s work• “Don’t let the sun shine on bad code”925Pitch It• If your design becomes more brittle over time– Pitch it– Don’t spend good money after bad• Try incremental refactoring first– But when that’s not feasible, pitch it– You’ll save time and money26Working• Create a list of tests you want to write– Start with the simplest– Add tests as you go• End the day with a failing test–