Date post: | 11-May-2015 |
Category: |
Technology |
Upload: | steve-ross |
View: | 1,165 times |
Download: | 3 times |
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