TorontoRb   Intro to BDD
Upcoming SlideShare
Loading in...5
×
 

TorontoRb Intro to BDD

on

  • 780 views

Intro to BDD and how to integrate it into your development workflow. Reviewing some popular libraries and how to get started with them.

Intro to BDD and how to integrate it into your development workflow. Reviewing some popular libraries and how to get started with them.

Statistics

Views

Total Views
780
Views on SlideShare
780
Embed Views
0

Actions

Likes
1
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Introduce yourself <br /> <br /> My name is... <br /> <br /> I am the Senior Software Architect at NuLayer. <br /> <br /> Tonight I am going to give you a brief introduction to Behaviour Driven Development. <br /> <br />
  • - first heard about BDD about 3 years ago (on and off) <br /> <br /> Dan North has a great article [Click for article] <br /> - first published in (translated into 2 other languages) <br /> - a must read if you are interested in BDD <br /> <br /> - Dan has been writing/talking about BDD for a long while before that. <br /> - he was <br /> - Applying agile practices like TDD to numerous projects <br /> - He kept hitting the same stumbling block <br /> <br /> He running into the same problem; As he says it <br /> &#x201C;Programmers wanted to know where to start, what to test and what not to test, <br /> how much to test in one go, what to call their tests, and how to understand why a test fails.&#x201D; <br /> <br /> The beginning of BDD was when Dan decided to <br /> - changed the language they were using. <br />
  • We start with a dialog between you and your client; You ask a simple question like [Read Question] <br /> <br /> In TDD we might start with a test name like &#x201C;account_init_test&#x201D; <br /> <br /> we write things using natural language <br /> <br /> &#x201C;First we say what we are describing&#x201D; <br /> <br /> &#x201C;Second we state our expectations through examples&#x201D; <br /> <br /> we could write it like this; [Click] <br /> <br /> Describe; <br /> <br /> Rspec gives us options <br /> - we could also write it like this; [Click] <br /> <br /> <br />
  • We start with a dialog between you and your client; You ask a simple question like [Read Question] <br /> <br /> In TDD we might start with a test name like &#x201C;account_init_test&#x201D; <br /> <br /> we write things using natural language <br /> <br /> &#x201C;First we say what we are describing&#x201D; <br /> <br /> &#x201C;Second we state our expectations through examples&#x201D; <br /> <br /> we could write it like this; [Click] <br /> <br /> Describe; <br /> <br /> Rspec gives us options <br /> - we could also write it like this; [Click] <br /> <br /> <br />
  • We start with a dialog between you and your client; You ask a simple question like [Read Question] <br /> <br /> In TDD we might start with a test name like &#x201C;account_init_test&#x201D; <br /> <br /> we write things using natural language <br /> <br /> &#x201C;First we say what we are describing&#x201D; <br /> <br /> &#x201C;Second we state our expectations through examples&#x201D; <br /> <br /> we could write it like this; [Click] <br /> <br /> Describe; <br /> <br /> Rspec gives us options <br /> - we could also write it like this; [Click] <br /> <br /> <br />
  • Here is what that example might look like. <br /> - Notice the before and after blocks to setup and clean up for us. <br /> <br /> We also have some code in our example <br /> - Its actually pretty readable <br /> - notice the .should method; <br /> - we call this an expectation. <br /> - as the example reads; we expect it to be empty <br /> <br /> many decisions have already been made <br /> It might have been simpler to forgo the Money.new and just simply check that the starting balance was 0... <br /> <br /> But... Its all in that little $. The example called for 0 dollars, not a balance of 0 <br /> ... <br /> <br /> Dan was quoted as describing BDD as... [Next Slide] <br />
  • <br />
  • I first though of BDD as: <br /> - TDD with some special language <br /> - to get your head in the right place <br /> <br /> - TDD is primarily concerned with unit testing. <br /> - Its all about Red/Green; <br /> - red is a failing test, green is a passing test <br /> <br /> - The process (write, watch fail, min code to make it pass, watch it go green) <br /> - The problem with TDD <br /> - Where to start <br /> <br /> - BDD has this Red/Green push as well <br /> - actually more of a green, yellow, red, yellow, green thing... <br /> <br /> Back to what BDD is... [Next slide] <br />
  • Wikipedia tells us that... &#x201C;BDD focuses...&#x201D; <br /> <br /> - rely on testing (broken or working) <br /> <br /> BDD suggests we use natural language <br /> - Doing this we can; <br /> - Focus on why the code should be written <br /> - And avoid focusing on the technical details. <br /> <br /> A nice side effect <br /> - tests become readable <br /> - not just for developers either. <br /> - everybody on the team has a shot at reading the tests <br />
  • BDD is alot more then just special language on top of TDD. <br /> - gives us a clear path through the entire development process. <br /> <br /> [click to hide] <br /> Today we are only going to focus on a very small portion of BDD. <br /> <br /> Today we are going to learn some of the BDD language and use it as a TDD/test_unit replacement. <br /> <br /> Getting started like this: <br /> - easy to learn the language <br /> - to get your head in the right place <br /> <br /> <br /> <br />
  • BDD is alot more then just special language on top of TDD. <br /> - gives us a clear path through the entire development process. <br /> <br /> [click to hide] <br /> Today we are only going to focus on a very small portion of BDD. <br /> <br /> Today we are going to learn some of the BDD language and use it as a TDD/test_unit replacement. <br /> <br /> Getting started like this: <br /> - easy to learn the language <br /> - to get your head in the right place <br /> <br /> <br /> <br />
  • There are a few good options out there. Two of the more popular ones are Shoulda and RSpec. <br /> <br /> Shoulda is an extension of Test::Unit and works great on an existing project <br /> <br /> RSpec is a installs extra directories and scripts into your rails project. <br />
  • create sandbox app <br /> to play around with. <br />
  • 20 seconds on Gemfile; <br /> <br /> [Click to hide all but rspec lines] <br />
  • 20 seconds on Gemfile; <br /> <br /> [Click to hide all but rspec lines] <br />
  • Then you do a bundle install <br /> <br /> run the generate script from rspec_rails <br /> <br /> assuming all went well <br /> <br /> [Click] running rake spec should yield [Click] almost nothing <br />
  • Then you do a bundle install <br /> <br /> run the generate script from rspec_rails <br /> <br /> assuming all went well <br /> <br /> [Click] running rake spec should yield [Click] almost nothing <br />
  • [Click for tweaks to home directory] <br />
  • 5 seconds on the helper; <br /> [click to hide standard stuff] <br />
  • 5 seconds on the helper; <br /> [click to hide standard stuff] <br />
  • Here is a simple spec. <br /> <br /> In a rails project an easy place to stash this would be spec/models/my_first_spec.rb <br /> <br /> Notice the language: <br /> - describe (what is being described) <br /> - what is the requirement (N/A) <br /> - what is our expectation (it should work) <br />
  • Highlight the nice structure; <br /> - .rspec file makes things pretty &#x2018;--format nested&#x2019; <br /> <br /> Highlight the summary line; 1 example, 1 pending <br />
  • difference between pending example vs example <br /> - is a block [click to show block] <br /> <br /> Even though the block is empty rspec will still count it as a passing example. [Click] <br /> <br /> Now that we have a working example... lets get some expectations. <br />
  • difference between pending example vs example <br /> - is a block [click to show block] <br /> <br /> Even though the block is empty rspec will still count it as a passing example. [Click] <br /> <br /> Now that we have a working example... lets get some expectations. <br />
  • difference between pending example vs example <br /> - is a block [click to show block] <br /> <br /> Even though the block is empty rspec will still count it as a passing example. [Click] <br /> <br /> Now that we have a working example... lets get some expectations. <br />
  • Rspec Expectations <br /> - Should <br /> - should not <br /> <br /> Back to &#x201C;our first spec&#x201D; example [Click to show code] <br /> <br /> Expectations are: <br /> - the first one which just worked <br /> - and a new one which does something <br /> <br /> [Click to show should] Example Should <br /> [Click to show should_not] Example should_not <br /> <br /> [Click to show sample output] Here is the output after running the specs <br />
  • Rspec Expectations <br /> - Should <br /> - should not <br /> <br /> Back to &#x201C;our first spec&#x201D; example [Click to show code] <br /> <br /> Expectations are: <br /> - the first one which just worked <br /> - and a new one which does something <br /> <br /> [Click to show should] Example Should <br /> [Click to show should_not] Example should_not <br /> <br /> [Click to show sample output] Here is the output after running the specs <br />
  • Rspec Expectations <br /> - Should <br /> - should not <br /> <br /> Back to &#x201C;our first spec&#x201D; example [Click to show code] <br /> <br /> Expectations are: <br /> - the first one which just worked <br /> - and a new one which does something <br /> <br /> [Click to show should] Example Should <br /> [Click to show should_not] Example should_not <br /> <br /> [Click to show sample output] Here is the output after running the specs <br />
  • Rspec Expectations <br /> - Should <br /> - should not <br /> <br /> Back to &#x201C;our first spec&#x201D; example [Click to show code] <br /> <br /> Expectations are: <br /> - the first one which just worked <br /> - and a new one which does something <br /> <br /> [Click to show should] Example Should <br /> [Click to show should_not] Example should_not <br /> <br /> [Click to show sample output] Here is the output after running the specs <br />
  • Describe the matches <br /> <br /> .. Lets try some of these out. <br />
  • Describe the matches <br /> <br /> .. Lets try some of these out. <br />
  • Describe the matches <br /> <br /> .. Lets try some of these out. <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Breaking examples down inside of contexts... <br /> <br /> [Click to focus on new context] <br /> we are saying that these examples should <br /> - demo the eql matcher <br /> - demo the true/false matcher <br /> ... <br /> <br /> Lets see this run <br /> [Click to show output] <br /> <br /> [Click to focus on nested output] <br /> [Click to focus on pending summary] <br />
  • Walk through examples; <br /> - eql matcher <br /> - true/false matcher <br /> .... <br /> and running them we get [Click to show green] <br /> <br /> ---- [Intro to next slide] <br /> Lets build a switch bdd style <br /> <br /> if I were to: <br /> - describe the switch to a client <br /> - I would say something like <br /> <br /> a switch should: <br /> - turn on/off (toggle <br /> - know if its on <br /> - know if its off <br />
  • Lets start with a spec; <br /> <br /> /spec/models/switch_spec.rb <br /> <br /> and if we run it [Click] <br /> <br /> Bah!... not good. <br /> <br /> Oh wait. [Click] <br />
  • Lets start with a spec; <br /> <br /> /spec/models/switch_spec.rb <br /> <br /> and if we run it [Click] <br /> <br /> Bah!... not good. <br /> <br /> Oh wait. [Click] <br />
  • We add the model to the rails project <br /> <br /> and running the specs [Click] <br />
  • Lets spec out our switch <br /> <br /> DISCLAIMER <br /> - I wrote this example before wrote the intro to this switch example. <br /> - I did it wrong. <br /> - Had i thought about it by describing it to a client <br /> - I would not have written these first two examples <br /> <br /> So in the order I thought them up: [Click] and describe. <br /> <br /> And running them [Click] <br />
  • Lets spec out our switch <br /> <br /> DISCLAIMER <br /> - I wrote this example before wrote the intro to this switch example. <br /> - I did it wrong. <br /> - Had i thought about it by describing it to a client <br /> - I would not have written these first two examples <br /> <br /> So in the order I thought them up: [Click] and describe. <br /> <br /> And running them [Click] <br />
  • Lets spec out our switch <br /> <br /> DISCLAIMER <br /> - I wrote this example before wrote the intro to this switch example. <br /> - I did it wrong. <br /> - Had i thought about it by describing it to a client <br /> - I would not have written these first two examples <br /> <br /> So in the order I thought them up: [Click] and describe. <br /> <br /> And running them [Click] <br />
  • Lets spec out our switch <br /> <br /> DISCLAIMER <br /> - I wrote this example before wrote the intro to this switch example. <br /> - I did it wrong. <br /> - Had i thought about it by describing it to a client <br /> - I would not have written these first two examples <br /> <br /> So in the order I thought them up: [Click] and describe. <br /> <br /> And running them [Click] <br />
  • Lets spec out our switch <br /> <br /> DISCLAIMER <br /> - I wrote this example before wrote the intro to this switch example. <br /> - I did it wrong. <br /> - Had i thought about it by describing it to a client <br /> - I would not have written these first two examples <br /> <br /> So in the order I thought them up: [Click] and describe. <br /> <br /> And running them [Click] <br />
  • Lets spec out our switch <br /> <br /> DISCLAIMER <br /> - I wrote this example before wrote the intro to this switch example. <br /> - I did it wrong. <br /> - Had i thought about it by describing it to a client <br /> - I would not have written these first two examples <br /> <br /> So in the order I thought them up: [Click] and describe. <br /> <br /> And running them [Click] <br />
  • Starting on the first example... <br /> <br /> [Click] and we go red <br />
  • Now we shoot for green; <br /> <br /> Like TDD we aim for the smallest change to make the specs pass <br /> <br /> and if we run the specs we are green! [Click to run] <br /> <br /> Nope; still red... <br /> <br /> :state vs &#x2018;state&#x2019; [click to show the spec] <br />
  • Now we shoot for green; <br /> <br /> Like TDD we aim for the smallest change to make the specs pass <br /> <br /> and if we run the specs we are green! [Click to run] <br /> <br /> Nope; still red... <br /> <br /> :state vs &#x2018;state&#x2019; [click to show the spec] <br />
  • Now we shoot for green; <br /> <br /> Like TDD we aim for the smallest change to make the specs pass <br /> <br /> and if we run the specs we are green! [Click to run] <br /> <br /> Nope; still red... <br /> <br /> :state vs &#x2018;state&#x2019; [click to show the spec] <br />
  • Now we shoot for green; <br /> <br /> Like TDD we aim for the smallest change to make the specs pass <br /> <br /> and if we run the specs we are green! [Click to run] <br /> <br /> Nope; still red... <br /> <br /> :state vs &#x2018;state&#x2019; [click to show the spec] <br />
  • Make our adjustment to the spec <br /> <br /> are we green? [Click] <br /> <br /> Yes! <br /> <br /> Its ok to refactor your specs! <br />
  • Make our adjustment to the spec <br /> <br /> are we green? [Click] <br /> <br /> Yes! <br /> <br /> Its ok to refactor your specs! <br />
  • Make our adjustment to the spec <br /> <br /> are we green? [Click] <br /> <br /> Yes! <br /> <br /> Its ok to refactor your specs! <br />
  • Next starting in the off state <br /> <br /> Red at this point <br /> <br /> And we add an initialize method [Click] <br /> and we go green. <br />
  • Next starting in the off state <br /> <br /> Red at this point <br /> <br /> And we add an initialize method [Click] <br /> and we go green. <br />
  • Next starting in the off state <br /> <br /> Red at this point <br /> <br /> And we add an initialize method [Click] <br /> and we go green. <br />
  • and we continue; red to green/yellow <br /> <br /> <br />
  • and we continue; red to green/yellow <br /> <br /> <br />
  • and we continue; red to green/yellow <br /> <br /> <br />
  • and we continue; red to green/yellow <br /> <br /> <br />
  • We are starting to repeat ourselfs a bit. <br /> <br /> In this simple example that not a problem.... but... <br /> <br /> RSpec has a couple of nice ways to make our lives easier! <br /> <br /> [Click] Let <br /> <br /> [Click] Subject <br />
  • We are starting to repeat ourselfs a bit. <br /> <br /> In this simple example that not a problem.... but... <br /> <br /> RSpec has a couple of nice ways to make our lives easier! <br /> <br /> [Click] Let <br /> <br /> [Click] Subject <br />
  • And lets make this switch toggle... <br /> <br /> and after that we are green and we are done. <br /> <br /> Notes about this example; <br /> - had I had the discussion with the client i would know exactly what examples to write. <br /> - I would not have exposed the internal &#x2018;state&#x2019; to the test. <br /> - could have refactored our switch to use a boolean value <br /> - with out effecting our specs <br />
  • And lets make this switch toggle... <br /> <br /> and after that we are green and we are done. <br /> <br /> Notes about this example; <br /> - had I had the discussion with the client i would know exactly what examples to write. <br /> - I would not have exposed the internal &#x2018;state&#x2019; to the test. <br /> - could have refactored our switch to use a boolean value <br /> - with out effecting our specs <br />
  • And lets make this switch toggle... <br /> <br /> and after that we are green and we are done. <br /> <br /> Notes about this example; <br /> - had I had the discussion with the client i would know exactly what examples to write. <br /> - I would not have exposed the internal &#x2018;state&#x2019; to the test. <br /> - could have refactored our switch to use a boolean value <br /> - with out effecting our specs <br />
  • - Its ok to refactor your specs! (not as easy when they are inside of a key note presentation...) <br /> <br /> - Getting started small <br /> <br /> - don&#x2019;t fret skipping difficult things like &#x2018;uploading&#x2019; while you are learning <br /> - leave your self a pending example instead. <br /> - This is not an excuse to never write the spec! <br /> <br /> Get used to the simple matches <br /> - you will be suprised how far they will get you. <br /> <br /> Next time... mocks and stubs. <br />
  • - Its ok to refactor your specs! (not as easy when they are inside of a key note presentation...) <br /> <br /> - Getting started small <br /> <br /> - don&#x2019;t fret skipping difficult things like &#x2018;uploading&#x2019; while you are learning <br /> - leave your self a pending example instead. <br /> - This is not an excuse to never write the spec! <br /> <br /> Get used to the simple matches <br /> - you will be suprised how far they will get you. <br /> <br /> Next time... mocks and stubs. <br />

TorontoRb   Intro to BDD TorontoRb Intro to BDD Presentation Transcript