At work me and a friend are about to start a new project and since both of us like agile methodologies we are wanting use our project as a test case.  Joseph knows more about agile than I do; so he is kind of my coach on it.  One of the things we are planning on using is BDD.  Since I am not to familiar with it I engaged in a conversation with him about it and this is the log of the conversation.  I hope others find it useful.  In some respects it is _using_ BDD to learn about BDD, in an abstract theoretical way that is.

me: yo I was thinking it would be cool to try and use our project as maybe a test case for agile dev work and if successful maybe other projects can move to a more agile dev process.  Like it would be cool to have a CI solution going

josephholsten: yes

also, behaviour-driven.org is perhaps better than the alternatives

me: yeah.  Is there like a 2 paragraph what is BDD so i can understand that more going into reading the site because i am getting confused right now and am only in the intro.

or maybe i just need to read the intro page 2 or 3 more times

josephholsten: say that again?

me: sorry, stream of thought typing isn't really a good idea hehe.

Was curios if there is like a 2 paragraph description of BDD.  I am reading the intro page and running in circles because I don't get it to well.  Was thinking if i could get a really high level overview i could understand the intro more.

josephholsten: ah. BDD is a pattern language, which is why you feel that way.

You'll have that same difficulty with
"Pragmatic Programmers" and all those other pattern languages

So, where to begin?

me: so should I read something on pragmatic programming first?

josephholsten: no, I was referring to a book with a similar style

me: ah

gotcha

josephholsten: BDD is a process to go from hopes & dreams to a product that fulfils them

you might call it a design process, but it's also a style of specification, implementation, and verification

The idea is to start with a sense of what's wrong. Then write some stories of how to solve that problem

there is a suggested template for the stories

me: so like literal stories?

josephholsten: once you have stories, you can look at all of them and say: this one's more important than that one. it should come first

well, yes.

but there tends to be a more rigid format, to help turn them into an implementation

me: ah

josephholsten: here's the page on stories

http://behaviour-driven.org/Story

but don't worry about it much, they use a lot of terms without explaining

so you want to have a product that can make these stories real

but you can't do everything at once, so you pick a few to start with

(it doesn't matter which. some people will tell you it does, and if they're paying you, listen. otherwise: smile, nod, and start where you think you should)

Once you have a few stories, you want to look at them in more detail

josephholsten: you write down examples of their behavior. You write examples so detailed that you can be certain of whether the product behaves properly or not

these are acceptance tests

josephholsten: they call them acceptance criteria

you with me?

me: sorta

josephholsten: okay

perhaps I should go slower?

Ah, right you don't see the point yet, or know where I'm going

sorry

me: :)

josephholsten: so, you start with a hope, then you turn that into a story, then you turn that into acceptance criteria, then you turn that into a behavior specification, then you implement the behavior

me: sooo turn the behavior into code? just want to be sure.

josephholsten: sorta

josephholsten: the thing about bdd is that it emphasizes working implementations over all else

so very often, every last thing I said you would write would not be as prose, but code

I write stories, acceptance criteria, and behavior specifications as code

that way I know if it

I know if it is real or still being developed

me: so lets see if i can repeat this how I understand it.l

josephholsten: sure

me: So first you start with the idea of your project.  What you want it to be.

Next you write some stories of how to use and not to use the idea.  Then follow that with what specifically do we need to have to accomplish our stories

josephholsten: yes

preferably only spec'ing a little at a time

josephholsten: then implement

so while you've got the theory in your head, let's make it real

'behavior specification' is another name for a unit test

me: so kind of like we want to be able to copy multiple lines of text would be a concept/theory then we would break that down into how it works as a behavior spec?

josephholsten: exactly

your spec begins as a description

me: so can we expand of the idea above as an example maybe?

josephholsten: "should print the text 'hello world' to the console"

me: ok

josephholsten: then you turn it into a test

me: gotcha.  so the ShouldUpdateProfileDataOverWebService

is the story in a unit tests and once we develop that we write the code to accomplish that story?

josephholsten: http://pastie.caboo.se/153892

it is a test, but it's of more than a single unit

josephholsten: working...

me: k

i'm still reading on the BDD site

josephholsten: so look at the updated pastie, and it's just a interaction behavior specification

you specify the state behavior or interaction behavior before you write the implementation

the same is true for stories

you start with a literal story

start with a title

"should greet the user"

then give it a defined narrative:

as an <English speaking user>,

I want <to be greeted when the program starts>,

so that <I know I can start using the program>

that's a role, feature, and benefit. respectively

me: ok that makes more sense now

josephholsten: like it?

me: yeah

i do that in my head just not so formally

josephholsten: exactly!

that's what I've been telling BJ for months

me: LOL I do that in all parts of my life actually.

Like when I want to go on a camp out.  I walk through a typical weekend and pack for each "event" that is going to happen like Getup so i need xyz clothing wise then pack everything.  Then I pack for the extreme cases just in case

josephholsten: the only reason to do it formally is when you aren't sure what the next step is, you can just do what the framework says

me: yeah I like it actually.

josephholsten: and hopefully not waste energy on things you don't need yet

me: yeah. and later you can maybe go back and cover the various use cases that are rare if time permits

josephholsten: which is more what we need from bdd

me: yeah.  It makes sense to me now.  Do you mind if I make this chat log a blog post?

josephholsten: well, not necessarily rare, but not as valuable

yes, please do

I'm planning on turning it into a presentation for tonight

me: k sweet it is a great walk through i think so if it helps someone all the better.

sweet

so i guess we helped each other.

do you have some info about your presentation I can maybe post on my blog so people in Tulsa if any are reading can go?

If you are in Tulsa and would like to here Joseph's talk here is the information on it.

http://tulsarb.org/
Bank of America building, 24th floor
Vidoop offices
6pm

Address:

15 W 6th St Suite 2400
Tulsa, OK 74119