Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to TorontoRb Intro to BDD
Similar to TorontoRb Intro to BDD (20)
Recently uploaded
Recently uploaded (20)
TorontoRb Intro to BDD
- 1. Introduction to Behaviour Driven nickmulder
- 2. Behaviour Driven Development aka BDD
- 3. Behaviour Driven Development aka BDD http://blog.DanNorth.net/introducing-bdd/
- 8. Dan North says BDD is “ BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high- automation, agile methodology. It describes a cycle of interactions with well-defined ” outputs, resulting in the delivery of working, tested software that matters. Dan North November 2009
- 9. WTF I thought BDD was just TDD but with words like context and should?
- 10. BDD in a nutshell “ BDD focuses on obtaining a clear understanding of desired software behaviour through discussion with stakeholders. ” It extends TDD by writing test cases in a natural language that non-programmers can read. Wikipedia On Behaviour Driven Development
- 11. • One more time... BDD is Establishing the goals of different stakeholders required for a vision to be implemented • Drawing out features which will achieve those goals using feature injection • Involving stakeholders in the implementation process through outside-in software development • Using examples to describe the behaviour of the application, or of units of code • Automating those examples to provide quick feedback and regression testing • Using 'should' and allow the software's functionality to be questioned responsibility when describing the behaviour of software to help clarify • Using 'ensure' when describing responsibilities from side-effects of other elements outcomes in the scope of the code in question of software to differentiate of code. • Usingwritten to stand-in for collaborating modules of code which have not yet been mocks Wikipedia On Behaviour Driven Development
- 12. • One more time... BDD is Establishing the goals of different stakeholders required for a vision to be implemented • Drawing out features which will achieve those goals using feature injection • Involving stakeholders in the implementation process through outside-in software development • Using examples to describe the behaviour of the application, or of units of code • Automating those examples to provide quick feedback and regression testing • Using 'should' and allow the software's functionality to be questioned responsibility when describing the behaviour of software to help clarify • Using 'ensure' when describing responsibilities from side-effects of other elements outcomes in the scope of the code in question of software to differentiate of code. • Usingwritten to stand-in for collaborating modules of code which have not yet been mocks Wikipedia On Behaviour Driven Development
- 13. What are my Choices?
- 14. What are my Choices? Shoulda & RSpec
- 15. Getting started with RSpec
- 16. Getting started with RSpec rails new my_app -T
- 17. Gemfile
- 18. Gemfile
- 19. bundle install script/rails generate rspec:install
- 20. bundle install script/rails generate rspec:install rake spec
- 21. bundle install script/rails generate rspec:install rake spec No examples matching ./spec/**/*_spec.rb could be found
- 22. Bonus Points gem install autotest autotest-growl colored
- 23. Bonus Points gem install autotest autotest-growl colored # ~/.autotest require 'autotest/growl' # ~/.rspec --color --format nested
- 26. My First Spec
- 27. Run the spec rake spec
- 28. Going Green
- 29. Going Green
- 30. Going Green
- 36. RSpec Matchers
- 37. RSpec Matchers
- 38. RSpec Matchers
- 39. RSpec Matchers
- 40. Context
- 41. Context
- 42. Context
- 43. Context
- 44. Context
- 45. Implementing the Examples
- 46. Implementing the Examples
- 47. BDD Style Switch
- 48. BDD Style Switch
- 49. BDD Style Switch
- 50. Going Green
- 51. Going Green
- 52. Spec out our Switch
- 53. Spec out our Switch
- 54. Spec out our Switch
- 55. Spec out our Switch
- 56. Spec out our Switch
- 57. Spec out our Switch
- 58. Spec out our Switch
- 59. Red
- 60. Red
- 61. Green
- 62. Green Red
- 63. Green Red
- 64. Green?
- 65. Green!
- 66. Red
- 67. Green
- 68. Red Green
- 69. Red Green
- 70. Red Green
- 71. Red Green
- 72. Red Green
- 73. Time to Refactor
- 74. Time to Refactor
- 75. Time to Refactor
- 76. Toggle
- 77. Toggle
- 78. Toggle
- 79. Toggle
- 80. nickmulder
- 81. nickmulder [Links] http://blog.dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behavior_Driven_Development http://rspec.info/
Editor's Notes
- Introduce yourself My name is... I am the Senior Software Architect at NuLayer. Tonight I am going to give you a brief introduction to Behaviour Driven Development.
- - first heard about BDD about 3 years ago (on and off) Dan North has a great article [Click for article] - first published in (translated into 2 other languages) - a must read if you are interested in BDD - Dan has been writing/talking about BDD for a long while before that. - he was - Applying agile practices like TDD to numerous projects - He kept hitting the same stumbling block He running into the same problem; As he says it “Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.” The beginning of BDD was when Dan decided to - changed the language they were using.
- We start with a dialog between you and your client; You ask a simple question like [Read Question] In TDD we might start with a test name like “account_init_test” we write things using natural language “First we say what we are describing” “Second we state our expectations through examples” we could write it like this; [Click] Describe; Rspec gives us options - we could also write it like this; [Click]
- We start with a dialog between you and your client; You ask a simple question like [Read Question] In TDD we might start with a test name like “account_init_test” we write things using natural language “First we say what we are describing” “Second we state our expectations through examples” we could write it like this; [Click] Describe; Rspec gives us options - we could also write it like this; [Click]
- We start with a dialog between you and your client; You ask a simple question like [Read Question] In TDD we might start with a test name like “account_init_test” we write things using natural language “First we say what we are describing” “Second we state our expectations through examples” we could write it like this; [Click] Describe; Rspec gives us options - we could also write it like this; [Click]
- Here is what that example might look like. - Notice the before and after blocks to setup and clean up for us. We also have some code in our example - Its actually pretty readable - notice the .should method; - we call this an expectation. - as the example reads; we expect it to be empty many decisions have already been made It might have been simpler to forgo the Money.new and just simply check that the starting balance was 0... But... Its all in that little $. The example called for 0 dollars, not a balance of 0 ... Dan was quoted as describing BDD as... [Next Slide]
- I first though of BDD as: - TDD with some special language - to get your head in the right place - TDD is primarily concerned with unit testing. - Its all about Red/Green; - red is a failing test, green is a passing test - The process (write, watch fail, min code to make it pass, watch it go green) - The problem with TDD - Where to start - BDD has this Red/Green push as well - actually more of a green, yellow, red, yellow, green thing... Back to what BDD is... [Next slide]
- Wikipedia tells us that... “BDD focuses...” - rely on testing (broken or working) BDD suggests we use natural language - Doing this we can; - Focus on why the code should be written - And avoid focusing on the technical details. A nice side effect - tests become readable - not just for developers either. - everybody on the team has a shot at reading the tests
- BDD is alot more then just special language on top of TDD. - gives us a clear path through the entire development process. [click to hide] Today we are only going to focus on a very small portion of BDD. Today we are going to learn some of the BDD language and use it as a TDD/test_unit replacement. Getting started like this: - easy to learn the language - to get your head in the right place
- BDD is alot more then just special language on top of TDD. - gives us a clear path through the entire development process. [click to hide] Today we are only going to focus on a very small portion of BDD. Today we are going to learn some of the BDD language and use it as a TDD/test_unit replacement. Getting started like this: - easy to learn the language - to get your head in the right place
- There are a few good options out there. Two of the more popular ones are Shoulda and RSpec. Shoulda is an extension of Test::Unit and works great on an existing project RSpec is a installs extra directories and scripts into your rails project.
- create sandbox app to play around with.
- 20 seconds on Gemfile; [Click to hide all but rspec lines]
- 20 seconds on Gemfile; [Click to hide all but rspec lines]
- Then you do a bundle install run the generate script from rspec_rails assuming all went well [Click] running rake spec should yield [Click] almost nothing
- Then you do a bundle install run the generate script from rspec_rails assuming all went well [Click] running rake spec should yield [Click] almost nothing
- [Click for tweaks to home directory]
- 5 seconds on the helper; [click to hide standard stuff]
- 5 seconds on the helper; [click to hide standard stuff]
- Here is a simple spec. In a rails project an easy place to stash this would be spec/models/my_first_spec.rb Notice the language: - describe (what is being described) - what is the requirement (N/A) - what is our expectation (it should work)
- Highlight the nice structure; - .rspec file makes things pretty ‘--format nested’ Highlight the summary line; 1 example, 1 pending
- difference between pending example vs example - is a block [click to show block] Even though the block is empty rspec will still count it as a passing example. [Click] Now that we have a working example... lets get some expectations.
- difference between pending example vs example - is a block [click to show block] Even though the block is empty rspec will still count it as a passing example. [Click] Now that we have a working example... lets get some expectations.
- difference between pending example vs example - is a block [click to show block] Even though the block is empty rspec will still count it as a passing example. [Click] Now that we have a working example... lets get some expectations.
- Rspec Expectations - Should - should not Back to “our first spec” example [Click to show code] Expectations are: - the first one which just worked - and a new one which does something [Click to show should] Example Should [Click to show should_not] Example should_not [Click to show sample output] Here is the output after running the specs
- Rspec Expectations - Should - should not Back to “our first spec” example [Click to show code] Expectations are: - the first one which just worked - and a new one which does something [Click to show should] Example Should [Click to show should_not] Example should_not [Click to show sample output] Here is the output after running the specs
- Rspec Expectations - Should - should not Back to “our first spec” example [Click to show code] Expectations are: - the first one which just worked - and a new one which does something [Click to show should] Example Should [Click to show should_not] Example should_not [Click to show sample output] Here is the output after running the specs
- Rspec Expectations - Should - should not Back to “our first spec” example [Click to show code] Expectations are: - the first one which just worked - and a new one which does something [Click to show should] Example Should [Click to show should_not] Example should_not [Click to show sample output] Here is the output after running the specs
- Describe the matches .. Lets try some of these out.
- Describe the matches .. Lets try some of these out.
- Describe the matches .. Lets try some of these out.
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Breaking examples down inside of contexts... [Click to focus on new context] we are saying that these examples should - demo the eql matcher - demo the true/false matcher ... Lets see this run [Click to show output] [Click to focus on nested output] [Click to focus on pending summary]
- Walk through examples; - eql matcher - true/false matcher .... and running them we get [Click to show green] ---- [Intro to next slide] Lets build a switch bdd style if I were to: - describe the switch to a client - I would say something like a switch should: - turn on/off (toggle - know if its on - know if its off
- Lets start with a spec; /spec/models/switch_spec.rb and if we run it [Click] Bah!... not good. Oh wait. [Click]
- Lets start with a spec; /spec/models/switch_spec.rb and if we run it [Click] Bah!... not good. Oh wait. [Click]
- We add the model to the rails project and running the specs [Click]
- Lets spec out our switch DISCLAIMER - I wrote this example before wrote the intro to this switch example. - I did it wrong. - Had i thought about it by describing it to a client - I would not have written these first two examples So in the order I thought them up: [Click] and describe. And running them [Click]
- Lets spec out our switch DISCLAIMER - I wrote this example before wrote the intro to this switch example. - I did it wrong. - Had i thought about it by describing it to a client - I would not have written these first two examples So in the order I thought them up: [Click] and describe. And running them [Click]
- Lets spec out our switch DISCLAIMER - I wrote this example before wrote the intro to this switch example. - I did it wrong. - Had i thought about it by describing it to a client - I would not have written these first two examples So in the order I thought them up: [Click] and describe. And running them [Click]
- Lets spec out our switch DISCLAIMER - I wrote this example before wrote the intro to this switch example. - I did it wrong. - Had i thought about it by describing it to a client - I would not have written these first two examples So in the order I thought them up: [Click] and describe. And running them [Click]
- Lets spec out our switch DISCLAIMER - I wrote this example before wrote the intro to this switch example. - I did it wrong. - Had i thought about it by describing it to a client - I would not have written these first two examples So in the order I thought them up: [Click] and describe. And running them [Click]
- Lets spec out our switch DISCLAIMER - I wrote this example before wrote the intro to this switch example. - I did it wrong. - Had i thought about it by describing it to a client - I would not have written these first two examples So in the order I thought them up: [Click] and describe. And running them [Click]
- Starting on the first example... [Click] and we go red
- Now we shoot for green; Like TDD we aim for the smallest change to make the specs pass and if we run the specs we are green! [Click to run] Nope; still red... :state vs ‘state’ [click to show the spec]
- Now we shoot for green; Like TDD we aim for the smallest change to make the specs pass and if we run the specs we are green! [Click to run] Nope; still red... :state vs ‘state’ [click to show the spec]
- Now we shoot for green; Like TDD we aim for the smallest change to make the specs pass and if we run the specs we are green! [Click to run] Nope; still red... :state vs ‘state’ [click to show the spec]
- Now we shoot for green; Like TDD we aim for the smallest change to make the specs pass and if we run the specs we are green! [Click to run] Nope; still red... :state vs ‘state’ [click to show the spec]
- Make our adjustment to the spec are we green? [Click] Yes! Its ok to refactor your specs!
- Make our adjustment to the spec are we green? [Click] Yes! Its ok to refactor your specs!
- Make our adjustment to the spec are we green? [Click] Yes! Its ok to refactor your specs!
- Next starting in the off state Red at this point And we add an initialize method [Click] and we go green.
- Next starting in the off state Red at this point And we add an initialize method [Click] and we go green.
- Next starting in the off state Red at this point And we add an initialize method [Click] and we go green.
- and we continue; red to green/yellow
- and we continue; red to green/yellow
- and we continue; red to green/yellow
- and we continue; red to green/yellow
- We are starting to repeat ourselfs a bit. In this simple example that not a problem.... but... RSpec has a couple of nice ways to make our lives easier! [Click] Let [Click] Subject
- We are starting to repeat ourselfs a bit. In this simple example that not a problem.... but... RSpec has a couple of nice ways to make our lives easier! [Click] Let [Click] Subject
- And lets make this switch toggle... and after that we are green and we are done. Notes about this example; - had I had the discussion with the client i would know exactly what examples to write. - I would not have exposed the internal ‘state’ to the test. - could have refactored our switch to use a boolean value - with out effecting our specs
- And lets make this switch toggle... and after that we are green and we are done. Notes about this example; - had I had the discussion with the client i would know exactly what examples to write. - I would not have exposed the internal ‘state’ to the test. - could have refactored our switch to use a boolean value - with out effecting our specs
- And lets make this switch toggle... and after that we are green and we are done. Notes about this example; - had I had the discussion with the client i would know exactly what examples to write. - I would not have exposed the internal ‘state’ to the test. - could have refactored our switch to use a boolean value - with out effecting our specs
- - Its ok to refactor your specs! (not as easy when they are inside of a key note presentation...) - Getting started small - don’t fret skipping difficult things like ‘uploading’ while you are learning - leave your self a pending example instead. - This is not an excuse to never write the spec! Get used to the simple matches - you will be suprised how far they will get you. Next time... mocks and stubs.
- - Its ok to refactor your specs! (not as easy when they are inside of a key note presentation...) - Getting started small - don’t fret skipping difficult things like ‘uploading’ while you are learning - leave your self a pending example instead. - This is not an excuse to never write the spec! Get used to the simple matches - you will be suprised how far they will get you. Next time... mocks and stubs.