BDD has a variety of testing tools surrounding it in a number of languages. Since I'm primarily in the .NET world (looking to expand that soon), I've dabbled with MSpec and had a lot of fun/success in creating descriptive tests that spoke the language of the business and communicated value. That was my first experiment in the world of domain drive design in an agile process.
The one thing these tools have in common is that they promote outside-in development. In BDD that literally means starting at the touch point with the consumer/customer/stakeholder. For most applications, that's a GUI of some sort but for others it may be a web service or something similar.
I've seen outside-in development go by a couple names like story driven development or acceptance test driven development. Unless I'm mistaken, they're both trying to achieve the same goal. What outside-in development is trying to do is make the software customer-oriented not unlike the agile processes that fit with this thinking. You start building the software from the customer's point of view based on their specification of it (usually as a story). Coupled with agile, you're doing something along the lines of rapid prototyping (with a bit more discipline). It's also keeping you focused on what the customer wants. It discourages gold plating and extra work that are typically waste.
<tangent>
I don't like to say gold plating because I know there are those developers that think that discouraging gold plating is like discouraging free thought and creativity. I would disagree. The hard pill for us to swallow is that what we perceive to be a "better way to do things" is not from the perspective of the actual consumers of the application. They may have no use for the bells and whistles that we believe to be productivity boosters. What it may be doing instead is creating excess inventory that costs money but has no ROI.
However, if you're in an agile process (or even if you're not), don't despair! Agile, by its very nature, relies on high-bandwidth communication. Reach out to the customer and communicate your creative thoughts and ideas. They will rely on your expertise in this arena and most times accept your recommendations. But, just remember, if they don't find use for your widget/tool/interface then don't do it (at least on company time :-P)!
</tangent>
Sooooo this is what I've understood so far. I am by no means an expert on outside-in development and I'm still trying to understand the practice. In the past, I've worked from the application logic and worked my way downwards. I haven't done it from the UI down which is certainly an interesting experiment. I'm also coming to find that I haven't done nearly enough acceptance/functional testing in my travels.
I plan on following up this post with my first attempt at doing outside-in development. I need to find a good book on it. I'm pretty sure the
RSpec Book is probably what I'm looking for but any recommendations are appreciated. In the meantime, I've just been reading blogs, articles and comments. One such blog I ran into has a tremendous amount of insight into testing and offers good information to get you started on writing acceptance tests using ASP.NET MVC and some other tools and frameworks.
Check out Steve Sanderson's blog to get some really great information.
