test will best move your code towards completion. Red: Write a very small amount of test code. Only a few lines... usually no more than five. Run the tests and watch the new test fail. Green: Write a very small amount of production code. Run the tests and watch them pass. Don't worry much about elegance and design purity.
tests are passing, you can make changes without worrying about breaking anything. Look for duplication and other "code smells." If you see something that doesn't look right, but you're not sure how to fix it, that's okay. Repeat: Do it again. You'll repeat this cycle dozens of times in an hour.
proof, Without more wider and more overt test” —Othello, Act 1 Scene 3 William Shakespeare is less about testing is more about design results in Clean Code That Works is more addictive than caffeine! leaves you Test Infected
TDD as tool to deliver high-quality code to testers Tests tend to focus on internal of an Object Testing what an object is rather than what the object does
changes how you think about programming Focus shifts to interactions between people and systems objects Focus moves away from structure of objects, and that is how it should be!
wrote the seminal post: A New Look at Test Driven Development Stop thinking in terms of tests Uncle Bob Martin: “Specification, not Verification” Verification or tests just ensure code works Specification defines what code ought to do
North wrote the seminal blog post Introducing BDD He said many coders were confused about where to start what to test what not to test how much to test what to call the tests how to understand why a test fails
Test method names should be sentences Simple sentences keep test methods focused Expressive test names help when a test fails “Behaviour” is a more useful word than “Test”
Test method names should be sentences Simple sentences keep test methods focused Expressive test names help when a test fails “Behaviour” is a more useful word than “Test”
was Domain Driven Design by Eric Evans ”model a system using a ubiquitous language based on the business domain, so that the business vocabulary permeates right into the codebase.” BDD gives us that ubiquitous language for analysis
format: As a [X] I want [Y] so that [Z] A story is interchangeably called a feature But, a feature can be broken down into stories It helps to distinguish between a feature and a story
format: In order to [Z] # Z is usually a benefit As a [X] I want [Y] This is fast becoming the popular format Subtle shift in emphasis by putting benefit first Helps keep the focus on the outcome ...and not on the detail of the feature
Given some initial context, When an event occurs, Then ensure some outcomes. Given/When/Then – The BDD triad Features and Scenarios help nail the requirements as well as the acceptance criteria
in credit Given the account is in credit And the card is valid And the dispenser contains cash When the customer requests cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned
overdrawn past the overdraft limit Given the account is overdrawn And the card is valid When the customer requests cash Then ensure a rejection message is displayed And ensure cash is not dispensed And ensure the card is returned
overdrawn past the overdraft limit Given the account is overdrawn And the card is valid When the customer requests cash Then ensure a rejection message is displayed And ensure cash is not dispensed And ensure the card is returned
Upfront planning, analysis and design all have a diminishing return We shouldn't do less than we need to get started But... any more than that is wasted effort! Deliver stakeholder value Do only things that deliver value Or that increases your ability to deliver value It's all behavior
JBehave to Ruby as RBehave and it was merged into RSpec as Story Runner In 2008, Aslak Hellesøy rewrote Story Runner and called it Cucumber as suggested by his fiancée His plan was to merge it back into RSpec But Cucumber has seeds and it sprouted! It supports many languages now