1. TDD,BDD and Unit Testing in Ruby @RoyOsheroveroy@osherove.com

2. A Test Driven Life Approach  Expect Something big  Expect many smaller things as part of it

3. A Test Driven Life Approach  Acceptance Test  Fill in the gaps with Specs, Unit and Integration Testing

4.  Engineering methodologies (waterfall for example..)  Agile (flexible & lightwheight) Methodologies  eXtreme Programming  Test Driven Development Team Agile - All rights reserved Putting TDD in Context

5. What is a ‘Unit’?

6. Unit Of Work Production Code Unit Of Work Production Code Unit Of Work Return Value/Exceptio n Noticeable State Change 3 rd Party call Public API Test

7. Production Code Unit Of Work Production Code Unit Of Work Return Value/Exceptio n Public API Assert Test

9. Production Code Unit Of Work Production Code Unit Of Work Noticeable State Change Test Public API Assert

11. Noticeable System Behavior Change  Noticeable by a user of the public API,  at the same level of the entry point that made the change.  ACT and ASSERT on the same level of APIs.

12. Production Code Unit Of Work Production Code Unit Of Work 3 rd Party call Test Public API Assert 3 rd Party Unit Of Work

13. Production Code Unit Of Work Production Code Unit Of Work 3 rd Party call Test Public API Assert 3 rd Party Unit Of Work Mock

15.  Easier to find bugs  Easier to maintain  Easier to understand  Easier to Develop Team Agile - All rights reserved Unit Testing makes your developer lives easier

16.  Not structured  Not Repeatable  Not on all your code  Not easy to do as it should be  A framework is missing Team Agile - All rights reserved All devs have already done Unit testing

17.  Original was for SmallTalk  Kent Beck and Erich Gamma  Ported to Various languages and platforms  JUnit, CppUnit, DUnit, VBUnit, RUnit, PyUnit, Sunit, HtmlUnit, …  Good list at www.xprogramming.com  Standard test architecture  Introducing RSpec Team Agile - All rights reserved The xUnit Frameworks

18. Frameworks  Test-Unit  Minitest  RSpec

19. Acceptance Frameworks  Cucumber  Steak  Turnip

24. Demo

25.  Make it Fail  No code without a failing test  Make it Work  As simply as possible  Make it Better  Refactor Team Agile - All rights reserved Test-Driven Development

26. Demo

27. String Calculator Osherove.com/kata

28. Demo String Calc

29. Simplicity Team Agile - All rights reserved

31. Simplicity take 2  As many assumptions as you can  Then debunk them one by one

32. Example  The input will always be empty  - wrong, if I send in a …  The input will always be one number if it is not empty  - wrong, if I send in …

33. Common Questions

34.  Think through the requirement  Think about the design and usability of the API  There’s never time to write it afterwards  You write much less tests (if at all) otherwise Team Agile - All rights reserved Why write the test before the code?

35.  Make sure the test does not have a bug  Make sure you’re testing the right thing  Define a small problem to solve  When the test passes, you are done  If you can’t write that test, you may  Not understand the requirement  Have over designed things (not testable)  Not have a small enough problem to solve Team Agile - All rights reserved Why make it fail first?

36.  Force you to write more tests you hadn’t considered  Simpler solutions are easier to maintain  Better code coverage of tested code Team Agile - All rights reserved Why solve it as simply as possible?

37.  Constantly improve the design of the code  Unit tests act as safety net  Remove duplication, improve readability and maintainability  You’ll need to when things change (requirements, your understanding of them, other factors..) Team Agile - All rights reserved Why Refactor?

38.  60% of the features you build won’t be used  Hopping between tasks can leave stuff undone  Something working is better than nothing  Meanwhile requirements may change, you lose less work (simpler solution, less time).  Small units of work are easier for people – better life!  Feeling of accomplishment that stuff is done Team Agile - All rights reserved Why work incrementally?

39.  It’s a much bigger problem to solve  Longer time to “green bar” feeling  You won’t know you have good code coverage  Solution probably more complex than it could have been  To support all tests at once  Also takes longer to create, more possibility of undetected bugs Team Agile - All rights reserved Why not write many tests at once?

40.  Implement – 7d  Testing – 3d  Fix Bugs – 3d  Testing – 3d  Fix Bugs – 2d  Testing – 1d  Release(19d)  Implement – 14d  Testing – 3d  Fix Bugs – 2d  Testing – 1d  Fix Bugs – 1d  Testing – 1d  Release(22d) Team Agile - All rights reserved Scenario

41.  Potential “Production Bugs” reduced by up to 90% - > more stable product  Better designed interfaces  API Documentation  Safety net for past and future  Happier customer  Happier coders Team Agile - All rights reserved ROI

42.  Implementat – 7d  Integration – 7d  Testing – 3d  Fix Bugs – 3d  Testing – 3d  Fix Bugs – 2d  Testing – 1d  Release(26d)  Implement – 14d  Integration – 2d  Testing – 3d  Fix Bugs – 2d  Testing – 1d  Fix Bugs – 1d  Testing – 1d  Release(24d) Team Agile - All rights reserved Scenario

43. Questions?