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
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
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
but there tends to be a more rigid format, to help turn them into an implementation
josephholsten: here's the page on stories
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?
perhaps I should go slower?
Ah, right you don't see the point yet, or know where I'm going
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: 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
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
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?
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"
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?
it is a test, but it's of more than a single unit
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?
i do that in my head just not so formally
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.
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.
Bank of America building, 24th floor
15 W 6th St Suite 2400
Tulsa, OK 74119