Session Duration: 60 minutes
Session Format: Live Coding w/Commentary
We all know the basic concepts of Test Driven Development:
* Write the test before you write the code
* Red, Green, Refactor
* Take small steps
* Make it work then make it clean, etc.
But what about the more subtle nuances of test driven design? What about London with mocks and stubs vs traditional Uncle Bobian TDD? How do you decide to drive from the outside vs the inside? What about custom matchers to make tests more expressive? Nested contexts for different sets of examples? Where is the line between BDD and TDD and when should we cross it?
In this live coding session, half the session will be test driving a simple problem using outside-in London style TDD, the other half will start over using inside-out traditional TDD. The focus will be on following the four rules of simple design:
* Software works as intended and you can prove it
* Minimize duplication
* Reveals the intent of the programmer
Double note: This isn't cucumber. This isn't story/acceptance testing. This is Unit level BDD.