Completely Test-Driven


Published on

This presentation outlines the philosophy, concepts and tools your team needs to completely test drive your products efficiently, from the front end down. It will define what unit tests and TDD are, and cover acceptance testing and ATDD with Cucumber, behavior driven development (BDD) and various test structures, mock objects, and fluent matchers.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Completely Test-Driven

  1. 1. Completely Test-Driven @iantruslove UCAR Software Engineering Assembly, Feb 21, 2012
  2. 2. What’s In It For Me?•  “So, that TDD sounds great and all, but what about <thing>?”•  See some techniques that really are necessary for TDD (and some others that are just cool)•  Start TDD?!
  3. 3. Outline•  TDD Refresher•  FIRST: Good Unit Tests•  For business’s sake, AT!•  The Test Double family•  Testing the UI?•  External resources, aka “What about the DB?”•  Reality: Legacy Code•  Wrap-up
  4. 4. TDD Refresher* Well, almost…
  5. 5. TDD RefresherBehavior-Driven Development style –  (“should” instead of “assert”)
  6. 6. TDD Refresher
  7. 7. TDD Refresher Challenges
  8. 8. FIRST: Good Unit Tests
  9. 9. FIRST: Good Unit Tests Fast Independent Repeatable Self-verifying Timely
  10. 10. FIRST: Good Unit Tests Test behaviors, not methods –  Don’t test your privates?
  11. 11. FIRST: Good Unit TestsEach test should test only one thing –  One assertion per test?
  12. 12. FIRST: Good Unit Tests Only one “real” class per test –  Mock the collaborators –  But don’t mock values (e.g.
  13. 13. FIRST: Good Unit Tests Smell: Test code is hard to read –  not enough refactoring
  14. 14. FIRST: Good Unit TestsSmell: Big ripples of red during changes –  not enough refactoring, tests are too complex
  15. 15. For business’s sake, AT!
  16. 16. For business’s sake, AT!•  Acceptance Criteria are specifications for what the software needs to do, written in domain language, by domain experts.•  Acceptance Tests (ATs) are executable Acceptance Criteria.•  Unambiguous, executable, repeatable specifications and documentation
  17. 17. For business’s sake, AT!Given {a context}When {an event occurs}Then {an observable outcome}
  18. 18. For business’s sake, AT! Drive the TDD loop with an AT
  19. 19. For business’s sake, AT!Cucumber specification:
  20. 20. For business’s sake, AT!Java step implementations:
  21. 21. For business’s sake, AT!Smell: ATs with lots of technical details –  you’re using ATs instead of UTs, or not testing from the outermost point of view
  22. 22. For business’s sake, AT! Smell: ATs keep breaking –  not abstract enough; perhaps too imperative
  23. 23. The Test Double family
  24. 24. The Test Double family
  25. 25. The Test Double family(“Mock object” often means Test Double)In increasing order of trickiness: –  Dummy object –  Stub –  Mockthis != Meszaros’ xUnit Patterns != Sinon.JS
  26. 26. The Test Double familySmell: Enormous effort setting up mock –  pull the complexity into e.g. domain façade objects
  27. 27. The Test Double family Smell: Lots of test doubles in a test –  poor encapsulation
  28. 28. Testing the UI?
  29. 29. Testing the UI?Diminishing returns: can you write anautomated test to tell you whether the UI looksnice? Flows well? Yes, but at what cost?!
  30. 30. Testing the UI?Prefer unit test over integration test over AT
  31. 31. Testing the UI?A strategy: –  Unit test event handlers –  Custom DSLs –  Few end-to-end ATs
  32. 32. Testing the UI?Watir WebDriver – acceptance test
  33. 33. Testing the UI?JavaScript – unit test
  34. 34. External resources, aka “What about the DB?”
  35. 35. External resources, aka “What about the DB?” Mock it Need to mock an interface, But I bet there’s no clean interface to mock ⇒  Adapt: wrap it first!
  36. 36. Reality: Legacy Code
  37. 37. Reality: Legacy Code•  It’s hard. Don’t start here.•  Fowler’s Refactoring book – small, safe changes•  Wrap in tests•  Improve what you touch – “shine a light”•  100% TDD any new code•  Feathers’ Legacy Code book
  38. 38. Wrap-upTDD Getting Started Guide™:1.  Find a Champion2.  Hit the books3.  Go slow4.  Find your frameworks5.  New project6.  Go all-out7.  Short loops8.  Refactor Mercilessly
  39. 39. Wrap-upThings to read:•  Growing Object-Oriented Software, Guided By Tests - Freeman & Pryce•  Test-Driven Development: By Example – Beck•  XUnit Test Patterns - Meszaros•  The RSpec Book - Chelimsky, Astels et al•  Clean Code: A Handbook of Agile Software Craftsmanship - Uncle Bob•  Test Driven: TDD and Acceptance TDD for Java Developers – Lasse Koskela•  Continuous Delivery - Humble & Farley•  Refactoring: Improving the Design of Existing Code - Fowler•  Working Effectively With Legacy Code - Feathers•  Gojko Adzik’s myriad web papers on automated testing
  40. 40. Questions Online at or