Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

I realize I have been a bit quiet the past few weeks, but we just kicked off the first iteration of a new project at work, so still settling into the project groove. Luckily, the team I am on is outstanding, so there has been good progress made for the first iteration.

Now, for the real purpose of this post. I've been a TDD enthusiast for about a year now and have been reading and watching videos about BDD the past few months and I am really intrigued. I have been trying it over the past week (using Scott Bellware's SpecUnit.NET) and I have to say it feels very powerful, but there are still some disconnects for me.


First, I understand that BDD is not a new technology meant to replace TDD. It is a way of doing TDD the way TDD was meant to be done. It can help developers avoid the pitfalls of the language of TDD. When doing TDD, developers can get sucked into the mental trap of "Unit Testing". TDD is supposed to be all about setting up expectations of things the system is should do. It's not about testing to make sure that your class works as expected, or you emailing service works, etc. It's about behavior the system should have. My disconnect here is: how does that drive your design? One of the great things about TDD is that it helps you to design loosely-coupled, highly cohesive systems, because you test everything in a fine-grained way. I write a test method that tests that validates when the IsValid method is called on my domain object that it verifies valid classes and throws exceptions when the domain object does not pass validation. But it is not necessarily behavior of the system. I guess the question is, do I consider internal, technology processes behaviors as well? Even though my customer may not care that the validation method works, they only care that valid objects are saved to the persistence medium. It's a subtle difference, but when developing a large enterprise system, there are tons of internal things that may not be represented on a User Story or Scenario, but are by-products of those user stories. Maybe my observations should be more fine-grained, or maybe I just don't care about the fine-grained?

Also, how does Integration Testing fit into the BDD development cycle? Do I still do my regular NUnit integration tests? or do I assume that if my observation works as expected that my integration works? My initial thought is that my integration tests remain the same and the BDD contexts, concerns, and observations are used to verify my behaviors from an end-to-end perspective.

I would be interested in seeing how people are doing BDD. Are you doing BDD, TDD AND integration tests on your system? Do you write a failing BDD observation, then red-green-refactor TDD and Integration Tests on the component pieces till each component piece passes and then, by most accounts, your observation should pass?

Again, I have just dived into this in the last couple of weeks, and suggestions and comments are welcomed.

Thanks in advance,


Posted on Sunday, September 28, 2008 6:48 PM BDD | Back to top

Comments on this post: Diving into Behavior Driven Development

# re: Diving into Behavior Driven Development
Requesting Gravatar...
Coming fresh from a BDD presentation by Raymond Lewellan (from CodeBetter), I can say that every time I am in a presentation on BDD I learn a little bit more. I took away that BDD is not a single person practice (or a pair) like TDD. BDD is a whole team thing, including your BAs, QAs, PMs, and users.

That is where you do stories and acceptance criteria.

The small part where writing your behaviors (tests, specifications, what ever you want to call them) comes in is very important. You want to make sure it is in the language of the user. So you make your tests as easy to understand as possible, even for someone that has never seen your code.
If you give a new guy your code base and have him work on bug detail, which is going to be easier for him to find tests for, the old way or the new way?


public class CalculatorTests
public void AddTest


public class when_using_a_calculator
public void it_should_add_two_numbers_together_correctly

When a user gives you a bug, they speak in a natural language. Your tests should be written in the same way because it helps anyone get to the point of finding and fixing the bug quick.

That's all I got for now.
Left by Robz on Oct 11, 2008 9:21 AM

# re: Diving into Behavior Driven Development
Requesting Gravatar...
I've posted a link to your post on :
Left by Benoit Guerout on Jul 24, 2009 10:30 AM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: