So BDD is behavior driven development. I started my last big project which went from 2003-2007 without ever having heard of this, and about midway through when I was suffering through poorly tested and brittle code, and basically relying on my customers to do my testing for me, I came across it and it seemed like the holy grail. So fast forward to January of this year, when I started teaching myself Ruby I was very very keen on integrating this into my development process and I have found it to be.... amazing.

I'm not an expert by any means, and am still refining my process. But at this point what I do is start a branch of my project with a cucumber .features file for my high level integration tests. And as I build out models I start by building out unit tests of an interface that doesn't exist yet using Rspec. This book was really critical to my understanding of the process.

But this whole process saves me from the two things that were my weakpoints in my last big project. 1. My tendency to start writing code without doing enough planning. And 2. My distaste for old-school testing, which at the time I saw as "Ok, now I need to click through every single possible scenario of my software. And that sucks"

There are also tools such as Watchr that will rerun your tests whenever you edit a file that you specify should be watched. This is great because you aren't able to duck from your tests and only use them when you feel like it.

I've pointed out RoR tools, but I know all languages support BDD tools. I noticed there are alot of old school programmers on this board, do you guys buy into the hype?

Edit: oops, I didn't add any fancy asterisks to show that it was an official thread. Feel free to edit jalex

I'm definitely old. Your post was the first I heard of BDD. I'm going to try specflow (for .net) now on a project I'm about to start. Thanks for posting this.

if anyone has a link to a beginner example walkthrough, id really appreciate it. something like this, but for BDD:
http://blog.extracheese.org/2009/11/...arted_tdd.html

It might be worth considering TDD before BDD (BDD is an extension of TDD). Some tools I would recommend for PHP developers are:

PHPUnit (http://www.phpunit.de/manual/current/en/) - An AWESOME TDD/BDD suite
Hudson (http://hudson-ci.org/) - For continuous integration development.

TDD/BDD is a MUST... it is near impossible to write good code without it.

EDIT: The phpunit manual has some pretty good info on testing in general.

I'm interested in using a C++ TDD framework like CppUnit/UnitTest++/Boost.Test, but the documentation on all of them is horrendous. Right now I'm trying to get Boost.Test to work, and keep running in to linker errors when compiling my test code. I found a blog with this snippet:

But I can't find where the source for this was installed (using Ubuntu 10.4) with my boost-dev install. The documentation on the boost site says:

but I'm not finding that directory anywhere. Anyone familiar with Boost.Test that could help out or point me in the right direction? I'd also settle for some relatively newbie oriented tutorials on other test libraries.

Unfortunately I have never used a C++ testing framework... hopefully someone else will be able to step in.

seems really cool

Really? So anybody writing a successful application or good code from the beginning of programming until about 10 years ago was performing the impossible?

I'll agree it is a useful tool, but the panacea it is often presented as -- it isn't.

This. Take the code implementing the 7 layer osi model. Those are absolutely huge C programs. That's some beautiful programming

The one thing I find tricky about it is that I often do major rewrites of the fundamental design of a module, and then find that so much of the testing code has to be thrown out and rewritten, or majorly overhauled. Is this a function of my being only 6 months into writing good OOP code and so I'm still making design mistakes that I won't be making once I have more experience, or is this just the nature of BDD?

Yes. Your problem probably lies in poor design of your interfaces. Interface design takes a lot of practice and experience. If you're interfaces don't change, your tests shouldn't need to change that often.

When creating an interface, take your time and sit back to think about the problem at hand from afar. Don't just mash on the keyboard and create the most logical interface that solves your current problem. See if there are ways to make the interface more generic so that it can be applied to a multitude of problems.

Yeah, I think I need to take a day or two just on the design stage instead of just plowing forward. My end design never bears any resemblance to the starting design, and that is majorly time consuming.. Although again, part of it is lack of experience. I just discovered the observer pattern and am doing a major rewrite of a module. But man is it worth it.