The Code Bucket

Behavior Driven Development Part 2 of n – Three Types of BDD

Lee Brandt — Mon, 06 Jul 2009 05:01:17 GMT

The Way I've Come To See BDD

Over the last year and a half, I have been moving from TDD to BDD. For those who don't know, this is not a tool or technology switch so much as it is a mental paradigm shift. Luckily, I didn't work in a lot of shops that ever did a lot of unit testing (testing units of code after you write them). Most often, we'd be under time crunches that forced PMs to make the decision to forego unit testing in order to meet a hard deadline that they got from some estimation crystal ball (that's a rant for another time). The positive outcome was that I didn't get sucked into many of the pitfalls that plagues those who came from shops that did more unit testing. However, I was still convinced it was about testing.

It's not about testing. As Dave Astels would say, "TDD is not aboot testing, it's aboot design." That's a good way to say it (without the Canadian accent, of course). TDD is about driving the design of your code based on what the consumer of that code specifies. The problem is, most people start with what the consumer needs and try and break that into small pieces of engineering and then test that. BDD takes a different approach.

BDD (for me) starts and ends with user voice. If you can't describe it in the user's language, you should stop and think about whether or not you're over engineering. It may start with a simple, "A user should be able to log in.", and that can spawn several scenarios. What should happen if the user's username is bad? their password? What happens if they DON'T have a username and password? Should we allow the user to "stay logged in"? Once the user successfully logs in, where should they be taken? All these things are tenets of good requirements gathering, and they become specifications for building what the consumer wants/needs. After much reading, discussing and practicing, I have seen two major styles of BDD. I've come to call them "Concentric Circle BDD" and "Context Specification".

Concentric Circle BDD

Concentric Circle BDD starts with a plain English scenario, written exactly as a user or BA might write it. The generally accepted pattern for these scenarios is the "Given, When, Then" syntax. For instance, "Given that I have a valid username and password, when I enter them in the login screen, I should be successfully logged in”. In this more "traditional" BDD style, you use a tool like Cucumber, JBehave or NBehave to write code that will pull in that text and parse it and execute it in a observable, provable way. Once you have a failing scenario, you drop into the inner concentric circle and begin writing more focused specifications, that observe small, independent pieces of that scenario. Once each inner piece is working, the scenario should be proven as well. Concentric Circle BDD is, I believe, what Dan North had in mind when he introduced BDD. If you've done any BDD with rSpec and Cucumber, using the two together leads to this type of BDD.

Using this outside-in circular approach, lets developers start right where the user leaves off. Take the story and scenarios and make them executable. Easy enough, and it overcomes one of the biggest barriers for those new to TDD and that is where to start. The main drawback, is that once developers get to the "inner" concentric circle, they might become lazy about keeping specs in the user's voice. It's easy to write a spec called "should_call_login_method_on_authentication_service" instead of calling it, "should_authenticate_user_against_registered_users". Staying in user voice makes it easier to ask a user how something in the system SHOULD behave, when you are unsure.

Context Specification

The Context Specification style of BDD foregoes the need for the Scenarios written in plain English and the need to write the wrapper code that will ensure they are executable. Instead it takes those scenarios into the "inner" circle directly. They break the scenarios into contexts and observations that look an awful lot like the Arrange/Act/Assert used in TDD (Which is all Given/When/Then is if you think about it). By breaking the larger scenario into smaller pieces, it's a bit easier to write the specifications that will prove the system does what it should, but it can be a bit of a disconnect for developers compared to the "outer" circle of the Concentric Circle method that takes the scenarios right out of the user's mouth. Some developers break the specifications into "Bullet Point" specifications, to make them easier to translate directly into Contexts and Observations. These specs are usually kept closer to user's voice when they are written, generally because they will be the artifacts presented to the user or Business Analyst when communicating what you have made the system do so far. It can, however, confuse those new to BDD when trying to figure out where to start.

A Third Approach

I might be late to the party and perhaps everyone else was doing this from the start, but I've recently noticed that our development team's Context Specification specs have evolved into almost a hybrid of the Concentric Circle and Context Specification approach. I don't think we moved there consciously, but I've noticed the BDD really getting easier and moving faster. Also, I've noticed a marked improvement in the quality and simplicity of our code. We are less and less often wandering down a path toward "over-engineering " a solution to a given problem. This approach rids us of having to write a bunch of code to parse and execute "User English" scenarios, but helps us to get started with an outside-in approach to specifying what the system should do. Here's how it works:

Everything is written as a spec, but the first spec almost mirrors the user's scenario. This "outer" circle is almost completely an "interaction" or "integration" specification. Most of what you see in the context is mocked objects, and each observation is an observation about how each piece interacts. Almost every observation is an "AssertWasCalled" (that I have extended with a ShouldRecieveCall method) call. To me, this represents the outer ring of the system. Then for every "interaction" observation, there is an opportunity to pull a concrete implementation of that mocked object (or subsystem) and specify how it should behave. This inside circle may be a subsystem that requires another interaction type specification, that observes how each piece of that subsystem interacts with every other piece in it. Eventually, you will move down to a very small independently observable specification. In the inner circle, you deal more with concrete classes. Specifying the implementation details of those behaviors. In the next few weeks, I will be blogging more about the samples of this approach. Leave some comments and let me know what you think. Am I on to something or just ON something?

Conversation Starter: The Tools DO NOT Make the Developer

Lee Brandt — Wed, 01 Jul 2009 01:52:34 GMT

I see a lot of talk online about this tool being better than that tool. It may sound obvious, but the tools do NOT make the developer. A tool is only a tool. If I gave my mother the best set of Snap-On tools that money could buy, she still wouldn’t be able to changer her own oil. On the other hand, if you gave my cousin Scotty a crescent wrench from Wal-Mart, he could probably rebuild a short block 350 in a weekend. Again, this may sound obvious, but the tools are only a way to help a good developer get the job done easier. A more inexperienced developer may even have MORE trouble with a good tool. I think that some people believe that the right tool will help a less experienced developer do things right. Generally, they just make it easier for him to turn a 300-line program into a 3000-line program.

Revelation About Lean Software and Estimation

Lee Brandt — Fri, 05 Jun 2009 00:32:19 GMT

Tell me if this sounds familiar:

Boss: "Hey man! So, it's time for our status meeting, huh? Okay. Let's get started."

You: "Well, we're working on the [deliverable] piece of [project]. We estimated it would take about 12 man-days."

Boss: "Uh-huh. How long have we been working on it?"

You: "About 8 man-days."

Boss: "And how much is left to do, do you think?"

You: "Probably 8 more man-days."

Boss: "What's the problem? Was there a hold-up, or a maintenance issue?"

You: "No. Once we got into [feature a], we saw some problems with the way it was implemented and we had to fix it to get the new stuff built. Also, when we estimated [feature b] we assumed the data was there, but it wasn't. [customer] also changed the requirements a bit regarding [feature c]."

Boss: "Okay, so you think we've got all the kinks worked out then?"

You: "As far as I can tell."

Boss: "So we're about 1/3 over budget. Can we safely say we'll be ready to test [deliverable] by [date 8 man-days from now]?"

You: "Barring anything huge, yeah."

If you've had that conversation more than twice, you've probably started adding 30% to your estimates, right? That’s what getting better at software estimation is about, right? You estimate, and you track your estimates and the actual time it took and you begin to learn how long it takes you (and your team) to build software. After years of this, you can start to gauge the skill level of the team and the complexity of the project compared to other projects and teams you’ve worked on and you become adept at answering the “estimate” question.

We then rail on about “esti-quotes”. How a customer takes an estimate, that’s just a gut feeling based on your experience, and starts planning delivery dates and budgets around it as if it were a quote. When we miss estimate, we try and adjust for it next time, but with each new project, team and technology comes new variables added to our esti-quoting ability, and anxiety around software estimation continues. But, what’re you gonna do?

Stop Getting Better at Estimating

“Quoi?”, you might say, “What’s wrong with that?” I know I’ve spent a good portion of my career trying to get better at estimating. But what if I DO get better? How will that help the business? They’ll be able to better plan delivery dates and budgets. That’s a good thing. What else? Anything? That’s all I can think of.

Now what if I used my actual times to get better at building software? What if I took all the features (even the ones where I was over estimate) and tried to find ways to build each one faster without sacrificing quality? What if I focused on building higher quality software without sacrificing speed? How might THAT benefit the business?

Is It Good for the Company?

If I build higher quality software (loosely coupled and highly cohesive with all the “bilities”), how does that affect the company? First, it will probably better solve the business problem for which it was intended. There will likely be less bugs to fix (lower maintenance cost). It will take less time to implement new functionality (lower maintenance cost). When there are bugs, they will be easier to find and fix (lower maintenance cost). Adding or replacing team members is less costly, because the code is easier to understand (lower maintenance cost). It will take less staff to maintain it than more poorly written software (lower maintenance cost). Are you seeing a pattern here? Lower Total Cost of Ownership. Is that better than being able to plan delivery dates and budget better?

Get Better At Writing Software

This was the epiphany I had yesterday after talking with a friend of mine about our approach to Kanban at work. We were talking about “getting better at it”, but I was talking about getting better at estimating and he was talking about getting better at building software. We talked past each other for about 15 minutes before a light went on in my head when he said, “So you may get better at “guessing” when software will be done, but so what? I’d rather get better at building software.”

I almost broke my face smiling. “You’re right.” I said, “I don’t want to work at the fair guessing peoples’ weight.”

I felt a burden lift off of me. I HATED trying to get better at estimating. I always felt like there was no structure to it. There isn’t. I can have 90 years of software experience and still “guess” wrong when someone asks me how long it will take to build [feature/deliverable/project].

If I get better at writing software (something I LOVE to do), then I will get better at delivering higher quality code faster. Who cares if I’m 1/3 over my estimate if I’m cranking out high quality code in half the time I was six months ago? And if I can prove I’m getting better, I’m “guessing” that’ll be okay with my customer. :0)

Permanent Marker on the White Board

Lee Brandt — Sat, 23 May 2009 01:41:20 GMT

A friend of mine, Troy, showed me this a while ago, and I thought this is probably one of the best office tips EVAR.

Have you ever been designing at the white board and accidentally wrote on it with a permanent marker? We use sharpies all the time for User Stories and it happened to me and I thought I was forced to live with the blue blemish on my whiteboard forever. Not true.

Take a regular white board marker (preferably the same color as the permanent marker) and write right over the top of the permanent mark. Let it dry and then erase as normal. The white board marker’s marks lift off the permanent marks!

This is especially useful for Kanban Boards.

Hope this helps someone as much as it has helped me.

~Lee

Resharper Tip: Navigating to a type

Lee Brandt — Mon, 18 May 2009 11:43:54 GMT

Obviously, my Tip of the Day is not meant to be a DAILY thing, so I thought I’d just rename to R# Tip. This is a pretty common one, but it’s possible some people aren’t aware of it.

For simple navigation, using ctrl+t or ctrl+shift+t can be invaluable. If you need to navigate to the file containing the Floogle type ctrl+t can get you there in a hurry. Hit ctrl+t and then type the name of the type you want to navigate to. You can also use capitalizxation to get you there faster. For instance, if you wanted the FloogleDTO to show up at the top, you could type the capitals and get there (e.g. type FDTO and the FloogleDTO type will be the only one matching).

But, if you need to get to a FILE and not a type name, use ctrl+shift+t and type the name of the file, same as you typed the name of the type before.

Try it out!

~Lee

Conversation Starter: To Sproc or NOT to Sproc

Lee Brandt — Fri, 08 May 2009 00:44:47 GMT

With the flat response from the series so far, I thought I’d stir the pot a little. Again, I am not trying to start a flame war, I just want to share my opinion and start a conversation about it.

I’ll start by saying that I am VERY comfortable using SQL. PL/SQL, T-SQL and even a bit of MySQL (ack). But after using NHibernate for the last year or so, I can honestly say that if I never write another sproc, I’ll be totally OK with that. I don’t think sprocs are evil, or ruin your application, for me it’s about testability. I like the fact that I can write a test that can check my query logic and never have to touch the database. I like the fact that I can test all four basic CRUD operations with one line of code! Most of all, I like doing it in C#.

There are times when there is no good substitute for a good sproc. But for most applications, I don’t see the point. SPECIALLY for CRUD operations.

What do YOU think?

Use NHibernate (With Fluent NHibernate) To Test Your CRUD In One Line Of Code

Lee Brandt — Fri, 08 May 2009 00:41:16 GMT

It’s true, I swear. It’s very simple to test if you can (C)reate, (R)ead, (U)pdate and (D)elete objects using NHibernate, and Fluent NHibernate makes it one (fluent) line of code!

Suppose we have an Employee object and we want to check that we can CRUD it AND reference to the Company (object) they work for in the mapping. It might look like this:

   1:  new PersistenceSpecification<Employee>(Session)

   2:      .CheckProperty(x => x.FirstName, "Dave")

   3:      .CheckProperty(x => x.LastName, "Jones")

   4:      .CheckProperty(x => x.MiddleInitial, "L")

   5:      .CheckProperty(x => x.DateOfBirth, new DateTime(2008, 11, 1))

   6:      .CheckProperty(x => x.Sex, _sex)

   7:      .CheckReference(x => x.Company, new Company{ CompanyID = 999, Name = "Wonder Wheels" })

   8:      .VerifyTheMappings();

Okay, it may not LOOK like one line of code, but I swear it is. One, long, fluent line of code.

Super sweet. If you’ve found better ways, post a comment, I LOVE to learn better ways.

Using NHibernate to Test Your Query Logic Without Touching The Database

Lee Brandt — Fri, 08 May 2009 00:28:20 GMT

That’s right, I said it, I’ve been doing it, and I abso-effin-lutely love it.

A few months ago my co-worker, Troy, posted a question on Stack Overflow. We were doing integration testing on a project we were working on, and as the object graph grew larger, the code required to test query logic became painful. Since I am a sissy and don’t like pain, Troy asked the question on SO about how we might do it less painfully, and we got this answer, and it totally changed our TDD/BDD lives.

The answer came from Garry Shutler, here and I’ll just sort of re-iterate it.

We created a base Interface for our repositories IRepository<T>, with a method IQueryable<T> All(). like so:

   1:  public interface IRepository<T>

   2:  {

   3:      IQueryable<T> All();

   4:      // whatever else you want

   5:  }

Then we implement it like so:

   1:  public IQueryable<T> All()

   2:  {

   3:      return session.Linq<T>();

   4:  }

We can then mock the IRepository<T>:

   1:  _repository = MockRepository.GenerateMock<IRepository<Customer>>();

Then Stub it to return a predefined list of objects that we are searching

   1:  _repository.Stub(repo => repo.All()).Return(TestCustomers.All().AsQueryable());

Then we can test the login of a Customer search by:

   1:  [Test]

   2:  public void should_return_customers_matching_first_name_last_name_and_dob()

   3:  {

   4:      Assert.That(_returnedMatches.Contains(_firstNameLastNameDOBMatch));

   5:  }

Many thanks to Garry for all the time he saved us, I immediately subscribed to his blog and have not been disappointed. I hope this helps someone as much as it has helped us.

Updates, Updates, Updates

Lee Brandt — Mon, 04 May 2009 06:30:35 GMT

1) OK, so Coders4Charities went well. The .NET User Group Meeting went well. Now it’s time to take a (small) break.

2) Most who know me probably already know, but I’ve been assigned as regional mentor for INETA membership for Missouri and Kansas. That will be consuming some of my time to get my head around who my UG leaders are and what they need from me, as well as helping fledgling UGs get started.

3) I won Fourth Place in Community Credit for the month of April! I get a sweet pin clock.

4) I will be speaking at the Twin Cities Developer's Guild on May 12th (Yikes next Tuesday) about BDD and I will be helping deliver some Mix 09 content at the Jefferson City .Net User Group on June 9th.

5) Today was my dog, Frieda’s 5th birthday, so we went to the park, got her a hamburger and Stacey made her a carrot cake. I know, we spoil her, don’t look at me like that.

6) I started my foray into Ruby programming tonight. I am mostly interested, because I am a freak for anything BDD, and RSpec is the gold standard to me of Context-Specification style BDD. Haven’t dived into Cucumber yet, but that’s coming soon. I am really liking the syntax of Ruby. It is easy to learn the basics and I am already creating classes and small programs. Now I just need a small project to sink my teeth into and drive the design out with behaviors using RSpec.

That’s about all for now. More information to come an all the new happenings. Stay tuned, dear readers!

~Lee

Waterfall Is The Perfect Methodology

Lee Brandt — Sat, 18 Apr 2009 11:53:24 GMT

Got your attention? Good. I’ll say it again: Waterfall is the perfect methodology.

It attempts perfection from the outset. Perfect requirements, perfect design, perfect development and perfect delivery in a perfect world. If you live in that world where requirements don’t ever change, then you should probably use a waterfall type methodology for developing your software; and you should drop me a line (although they probably won’t let you have anything sharp like a pencil to write with there).

For most of us, life is imperfect. Our development consists of false-starts, unsure or uninvolved customers, unskilled development teams and even less skilled project managers. Sometimes it’s amazing we’re able to pull it off. Our lives are a constant magic show; hoping to pull the rabbit out of the hat just one more time, while the audience sits in amazement secretly hoping (on some sadistic level) we fail. For most of us, that’s our lives. Perhaps not all of those things all of the time, but at least one of those things in play at all times. So how can any waterfall-ish-type methodology hope to help us deal with all that strife? Easy, it can’t. The very purpose of agile-type software methodologies is to help us deal with that imperfection.

Now I cut my teeth on waterfall-style development. Every time a deadline would pass or a budget would be blown we blamed ourselves. We thought, “We failed to follow the methodology correctly. We should have done more (insert methodology step here).” Boom. Process inflation. Pretty soon, we were writing more paper documents than actual code, and we were convinced this was a good thing. Fifteen pages of documentation for a fifteen-line program, and two-weeks to deliver. Sounds horrible, right? But that’s where we lived.

This week I started my first (small) project where we are attempting a Kanban/lean approach. It was absolutely liberating. Although we had less-than-stellar customer interaction, we had a point of contact we could bug whenever we needed to. We had only two developers, but we were both committed to the lean ideology. We set our sites on as little process as possible, and whenever we were unsure about something, we took a 15 minutes to hash it out and make a first-stab decision. It was phenomenal. We put up our first MMF (Minimum Marketable Feature) and broke it out into simple tasks. We didn’t spend a lot of time on the tasks, because we left ourselves open to being able to add or scrap a task when we needed to. At any time, you could come by the project board and see what we were working on, what was next and what was left to do to get this MMF delivered. We also allowed ourselves to say, “Hey, this process sucks, let’s try something else.” We stepped on each other’s toes a little and we fixed it as soon as it happened, quickly and without dwelling on the problem.

I also let myself deliver less than optimal code for some things. They were things that I knew we’d need to touch again, but it didn’t violate the SOLID principles, and as we got more information, we could rework that section to include new information with minimal effort.

And the work just flowed. We coded like monkeys with our asses on fire, and it felt good. We will get feedback on Monday from the users and see what changes need to be made and deliver that MMF. Then, we’ll pull the next MMF from the list, and start working it. I look forward to sharing more as we learn more, but this last week has been one of the most enjoyable in a long time. Thanks Troy!

~Lee