TDD,BDD and Unit Testing in Ruby

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

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

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

What is a ‘Unit’?

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

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

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

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.

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

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

 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

 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

 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  Standard test architecture  Introducing RSpec Team Agile - All rights reserved The xUnit Frameworks

Frameworks  Test-Unit  Minitest  RSpec

Acceptance Frameworks  Cucumber  Steak  Turnip

Demo

 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

Demo

String Calculator Osherove.com/kata

Demo String Calc

Simplicity Team Agile - All rights reserved

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

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 …

Common Questions

 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?

 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?

 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?

 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?

 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?

 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?

 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

 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

 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

Questions?