Behavior Driven DevelopmentSDXP/SDRuby
10,000 Foot Overview
Presentation Notes
• Don’t bother to pound this into your laptops• The whole thing is on:– http://calicowebdev.com/tblog
• There are some of my older blog posts about rSpec on:– http://calicowebdev.com/blog
Who The Hell Am I?
• I’d be asking the same question• Since 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, Sass
• OSS for last 10 years. Ruby/Rails since 2005• Still trying to get it right … or better
Not Me… But when I’m not programming, this would be a good place to be,
right?
Yikes!
• I have way more to talk about than I have time to talk.
• Big surprise.
Behavior Driven Development
• BDD 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.
Let’s See Some Side By SiderSpec Way Test::Unit Way‘dog’.length.should be(3) assert_equal(3, ‘dog’.length)
Post.should_not have(0).records assert(Post.count > 0)
Be patient. We’ll get to the real code.
Tools I Use
• Ruby• rSpec / rspec-rails• Cucumber• Faker• Fixjour• Again, all this stuff is on:
http://calicowebdev.com/tblog
Behavior vs. Test-Driven Development
TDD Way def test_foo_is_seven assert_equal(7, @foo) end
BDD Way describe @foo do
it "should be seven" do @foo.should == 7 end end
TDD vs BDD (Gratuitous Picture)
TDD: assert(true, @surfers.last.hit?)BDD: @surfers.last.should be_hit
The Premise:
• Readability of specs is better than “tests”• Writability of specs is more natural• It’s more likely that you will spec first
The Flow
• My personal work habits• Bounce around between Cucumber and rSpec• Create failing Scenario/Spec, then code to fix• Build coverage and edge case handling as I can• Try not to be too obsessive :)
Cucumber: In One Sentence
• Story-based description of behaviors• Divides specification into Feature > Scenario• Tests from way outside, ignoring internals• Not as focused as unit/functional tests• Easier to miss edge cases• Slower• Killer for covering full stacks like Rails
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
The Obligatory Rails Blog
• Developing from the outside in• First do a bit of plumbing• Next write features• Code to make them pass• Drill down to specs where necessary• Eventually, you want good coverage both at
acceptance (Cuke) and spec level
Top Related