This document discusses Behavior Driven Development (BDD) and compares it to Test Driven Development (TDD). BDD expresses tests as expected behaviors and results, while TDD focuses on checking that specific implementation details occurred. The document provides examples of BDD using rSpec and Cucumber compared to TDD-style tests. BDD tools like Cucumber describe features and scenarios from an outside-in perspective at a higher level than unit tests.

1. Behavior Driven DevelopmentSDXP/SDRuby10,000 Foot Overview

2. Presentation NotesDon’t bother to pound this into your laptopsThe whole thing is on:http://calicowebdev.com/tblogThere are some of my older blog posts about rSpec on:http://calicowebdev.com/blog

3. Who The Hell Am I?I’d be asking the same questionSince you asked (or not), Steve Ross (@cwd1)Calico Web Development, I build Web apps using primarily Ruby, rSpec, Cucumber and a bunch of other keen Ruby technologies like … um … Rails, Haml, SassOSS for last 10 years. Ruby/Rails since 2005Still trying to get it right … or better

4. Not Me… But when I’m not programming, this would be a good place to be, right?

5. Yikes!I have way more to talk about than I have time to talk.Big surprise.

6. Behavior Driven DevelopmentBDD is a way of expressing a set of expected results – i.e., tests.That is as opposed to TDD (test, blah) where you express what you think happened and check to see that it did.

7. Let’s See Some Side By SideBe patient. We’ll get to the real code.

8. Tools I UseRubyrSpec / rspec-railsCucumberFakerFixjourAgain, all this stuff is on:http://calicowebdev.com/tblog

9. Behavior vs. Test-Driven DevelopmentTDD Way def test_foo_is_seven assert_equal(7, @foo) endBDD Waydescribe @foo do it "should be seven" do @foo.should == 7 end end

10. TDD vs BDD (Gratuitous Picture)TDD: assert(true, @surfers.last.hit?)BDD: @surfers.last.shouldbe_hit

11. The Premise:Readability of specs is better than “tests”Writability of specs is more naturalIt’s more likely that you will spec first

12. The FlowMy personal work habitsBounce around between Cucumber and rSpecCreate failing Scenario/Spec, then code to fixBuild coverage and edge case handling as I canTry not to be too obsessive :)

13. Cucumber: In One SentenceStory-based description of behaviorsDivides specification into Feature > ScenarioTests from way outside, ignoring internalsNot as focused as unit/functional testsEasier to miss edge casesSlowerKiller for covering full stacks like Rails

14. I Lied. Another SentenceFeature: Stopping a Car In order to stop my car when I need to As a driver I want the brakes always to bring the car to a halt Scenario: Stopping under normal circumstances Given The ignition is on And The car is in motion When I step on the brake Then I should stop Scenario: Stopping when the accelerator is also depressed Given The ignition is on And The accelerator is also depressed When I step on the brake Then I should stop Scenario: Stopping when the accelerator is stuck Given The ignition is on And The accelerator is stuck When I step on the brake Then I should stop

15. The Obligatory Rails BlogDeveloping from the outside inFirst do a bit of plumbingNext write featuresCode to make them passDrill down to specs where necessaryEventually, you want good coverage both at acceptance (Cuke) and spec level