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
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.