Well a third TDD post and with mixed emotions I am here. On the one side, I have found BDD which (in my opinion) is far better then TDD.

What the h#ll is BDD you ask? Behavioral Driven Design. So what does that mean? It is development that is driven by the required behavior of your application(s). For example, if you need to write a online slot machine game, and the app you write behaves as an online slot machine game, you have successfully developed an online slot machine game. Ok, no duh! So what? How is that better then TDD where you would have written tests that would pass when you successfully written an online slot machine game?

Oooh, so go ahead and re-read that last question. Notice how it suggests that your artifact of the entire development process is a set of tests (and the implied working application), whereas the BDD version leaves you with a working application (and the implied tests).

That is the difference my friends, they are essentially the same but their terminology differs to emphasize what truly is important in the development process. The creator of BDD states that BDD is just TDD done right. And that's relevant to the effect that when using TDD it is too easy to fall into the trap of focusing on the tests. Not to imply testing isn't important, but they are a required evil in that if we never made mistakes, we would never need to write a single line of test code. As that's pretty much impossible (being human) testing and QA aims to mitigate the risk of the human factor.

So I still haven't really explained what the deal with BDD is, so here goes (and I apologize, an expert on the topic I am not.) To cite http://behaviour-driven.org/GettingTheWordsRight:

As far as using it, there are a few implementations ( http://en.wikipedia.org/wiki/Behavior_driven_development) for writing tests using BDD. The most popular is rSpec ( http://rspec.info/ ) for the Ruby platform. There are severl for Java, two (mostly dead) for MS .Net Framework, and vaious others (python, PHP, scala). There is a Google Video by the rSpec creator which is quite interesting: http://video.google.com/videoplay?docid=8135690990081075324&q=behavior%20driven%20development&total=27&start=0&num=10&so=0&type=search&plindex=1

I haven't had the opportunity to do anything with BDD, nor does it look like I will with the state of BDD as it stands today. I believe what has happened is that TDD ate it and we just have to make due. The tests we write should be behaviorial based even if the syntax of the testing domain language leaves us asserting like we're writing procedural code instead of the OO stuff us enterprise type developers eat all day :-/ Please rSpec guys, port your code to .net )

So, as you may have read in my previous rant regarding Test Driven Development, I am one of two developers participating in a test of TDD. The project is relatively small in scope and is mostly in a stand-alone “engine” so really, I think it's a pretty ideal test subject. If you were paying attention, your spidey sense started tingling when you read “…an is *mostly* in a stand-alone engine…” Yes, well, as one might guess the mostly is now causing us some grief. The subsystem I am working on interfaces with the main application so that it knows when it has work to do. In the final design of the subsystem, it is a stand-alone windows service consuming application events from the event queue. Now, not only is this a test TDD project, but also trying to incorporate some Agile/Scrum techniques. I think maybe this was a mistake. Agile makes more sense when you have a team of greater then two. So really I think we are suffering an issue stemming from Iteration grouping. Our 1st iteration is quite large and provides the framework for the rest. However, we are not able to take advantage of smaller implementation items that can be pushed to later interactions. Which causes us to call my sub-system from within the application that writes to the event queue, instead of just reading the event queue.

Now, here's where it really gets ugly. Due to how we have our name-spacing and library hierarchies, I have to move my subsystem completely out of the main project library and add it to the library code it interfaces with. And later I will have to move it back. The sub-system isn't huge, but that's a pain. 

And why didn't we see this coming? Because we are implementing from what the tests dictate we need, not what we will need for the entire project. Some may argue that the tests apparently were not complete and I agree. But I think it's a little unreasonable to know that from the test perspective until it's discovered by actual implementation. And these happen late in the game so a change is not only a change to the implementation but to the entire underlying tests which defeat the purpose of starting with the tests.

I guess one might further argue that TDD is not a replacement for detailed design. But I have to wonder, if the design is indeed so detailed as to reveal this issue before any coding (and I have seen designs that would fit the bill, as well as designed some of that ilk for prior employers) that one would not need to start with the tests as testing techniques would have been built into the requirements and design. Of course if you can , why not as it prevents people from getting time crunched and not implementing tests at all. But isn't the point of TDD to speed up and allow for iterative design (as well as pushing testing to the forefront, which I praise it for) ?

Regards!

Well folks, I'm here today to gripe about Test Driven Development (TDD if you can't live without an acronym). For those unfamiliar with it, the concept is (and feel free to correct me folks), one starts coding the unit tests firsts and implements the various classes/structures one needs to make the unit tests function. By the time all is done, you have a completed, working, and unit tested application. Re-factoring is embraced, heck there's even the TDD mantra: “Red, Green, Re-factor” (which comes from the Nunit paradigm of failed unit tests show up in red, running one's show up in green, and the re-factor refers to moving code around / renaming classes functions, etc to make more sense in one's project domain. Essentially it means, when just the test is written, it will fail as there is no concrete things to actually perform the tasks the test requires. Once you right just enough to make the tests pass, it passes (green) and is now ready to be “integrated” into the rest of the project with minor corrections).

Sounds good in theory doesn't it? Unfortunately, I don't live in Theory (houses are far too costly…) Why only in theory you ask? Well, as I sit here writing some tests so I can actually code the logic at some point, I'm looking at some diagrams of system interaction and whatnot and I frankly have no idea what the hell the tests are supposed to do… I have nothing to test, and using TDD, at best, I'll have tests that work and they will dictate what I build, unfortunately, the business wants me to build something particular. Depending on how well I do it, I could end up with something that is what they asked for, OR I could end up somewhere completely different if my understanding is off or I get pulled into the cadence of test code (vs. application logic which may be optimized for performance or maintainabililty, or whatever).

Basically, what I am getting at is, TDD is helpful when you don't know what you are building. However, if you don't know what you are building, why the hell are you building anything? Your time would be better spent fleshing out the requirements and the design. And before you say it (because I KNOW you're thinking it), “But the business doesn't know what they want, just what they think they want and I need to deliver what they NEED!” Well, I agree, so wouldn't expectations be better managed by working through requirements with the business so everyone is on the same page, wouldn't you know better what you are trying to build? I think so.

So where did it all go wrong? To put it bluntly, <flameShield on=”true”>Inexpereienced Developers are the majority of the workforce, and they often make mistakes (as doing is the only way to build experience, this is expected, and natural (albeit problematic)) TDD is just another way to homogenize the programming workforce to reduce the negatives.</flameShield> The downside is it also reduces the positives of having an “All Star” team. People also cite “quicker to market” reasons as by the time development is done there is something to deliver. This is just slight of hand to avoid the problems of managing business expectations. Cough up more frequent milestones and vi'ola, it looks like things are getting done. Unfortunately in reality, the same time is spent, and I propose, MORE time is being spent with TDD refactoring every pass and of course the final refactoring to align the new code with the existing code (which to be fair mostly amounts to renaming of classes, functions, etc, not so much new coding)

To me it just sounds like an excuse to not have to learn more formal documentation and requirements skills. I think knowing what you have to build is far more important then delivering it quickly. The old adage goes, “You can have it done Fast, Right, and Cheap. Pick any two.” This technique addresses the disconnect between the developers and the business that employs them who know very little about software development (think Business Programming here, not so much Software Development shops ) I firmly believe a much better approach is to teach the business what they need to know to manage software development projects, because we as developers don't have that skill, our magic is programming and archetecting, management is for the pointy haired boss types.

 Ok, I'm done. My apologies to anyone I've offended! Please feel free to correct me, I'd love to hear your thoughts!

I should probably mention Martin Fowler's book, “Refactoring. Improving the Design of Existing Code” as it's pretty good, although seasoned developers will likely know a lot of the items in the book, other books seem to reference this one (for example, “Refactoring to Patterns” by Joshua Kerievsky”)

-Regards!