SD Ruby BDD Talk


Published on

San Diego Ruby BDD Talk about rSpec and Cucumber

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

SD Ruby BDD Talk

  1. 1. Behavior Driven DevelopmentSDXP/SDRuby<br />10,000 Foot Overview<br />
  2. 2. Presentation Notes<br />Don’t bother to pound this into your laptops<br />The whole thing is on:<br /><br />There are some of my older blog posts about rSpec on:<br /><br />
  3. 3. Who The Hell Am I?<br />I’d be asking the same question<br />Since you asked (or not), Steve Ross (@cwd1)<br />Calico Web Development, I build Web apps using primarily Ruby, rSpec, Cucumber and a bunch of other keen Ruby technologies like … um … Rails, Haml, Sass<br />OSS for last 10 years. Ruby/Rails since 2005<br />Still trying to get it right … or better<br />
  4. 4. Not Me… But when I’m not programming, this would be a good place to be, right?<br />
  5. 5. Yikes!<br />I have way more to talk about than I have time to talk.<br />Big surprise.<br />
  6. 6. Behavior Driven Development<br />BDD is a way of expressing a set of expected results – i.e., tests.<br />That is as opposed to TDD (test, blah) where you express what you think happened and check to see that it did.<br />
  7. 7. Let’s See Some Side By Side<br />Be patient. We’ll get to the real code.<br />
  8. 8. Tools I Use<br />Ruby<br />rSpec / rspec-rails<br />Cucumber<br />Faker<br />Fixjour<br />Again, all this stuff is on:<br />
  9. 9. Behavior vs. Test-Driven Development<br />TDD Way<br /> def test_foo_is_seven<br /> assert_equal(7, @foo)<br /> end<br />BDD Way<br />describe @foo do<br /> it "should be seven" do<br /> @foo.should == 7<br /> end<br /> end<br />
  10. 10. TDD vs BDD (Gratuitous Picture)<br />TDD: assert(true, @surfers.last.hit?)<br />BDD: @surfers.last.shouldbe_hit<br />
  11. 11. The Premise:<br />Readability of specs is better than “tests”<br />Writability of specs is more natural<br />It’s more likely that you will spec first<br />
  12. 12. The Flow<br />My personal work habits<br />Bounce around between Cucumber and rSpec<br />Create failing Scenario/Spec, then code to fix<br />Build coverage and edge case handling as I can<br />Try not to be too obsessive :)<br />
  13. 13. Cucumber: In One Sentence<br />Story-based description of behaviors<br />Divides specification into Feature > Scenario<br />Tests from way outside, ignoring internals<br />Not as focused as unit/functional tests<br />Easier to miss edge cases<br />Slower<br />Killer for covering full stacks like Rails<br />
  14. 14. I Lied. Another Sentence<br />Feature: Stopping a Car<br /> In order to stop my car when I need to<br /> As a driver<br /> I want the brakes always to bring the car to a halt<br /> Scenario: Stopping under normal circumstances<br /> Given The ignition is on<br /> And The car is in motion<br /> When I step on the brake<br /> Then I should stop<br /> Scenario: Stopping when the accelerator is also depressed<br /> Given The ignition is on<br /> And The accelerator is also depressed<br /> When I step on the brake<br /> Then I should stop<br /> Scenario: Stopping when the accelerator is stuck<br /> Given The ignition is on<br /> And The accelerator is stuck<br /> When I step on the brake<br /> Then I should stop<br />
  15. 15. The Obligatory Rails Blog<br />Developing from the outside in<br />First do a bit of plumbing<br />Next write features<br />Code to make them pass<br />Drill down to specs where necessary<br />Eventually, you want good coverage both at acceptance (Cuke) and spec level<br />