sd ruby bdd talk

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