Thursday, July 24, 2008

BDD - The Two Approaches

I've been using BDD for a little while now and think I've gotten to grips with most of the ideas, however the more I learn the more questions I have. Rather than wait for answers I thought I'd blog about what I'm trying now, so when reading this keep in mind that these are just my current personal opinions and should be taken with a pinch of salt.

My intention was to write one big blog entry but it immediately got too long and unfocussed so I decided to break things out a bit and I thought I'd start by describing how I view BDD.

To me there are two styles of BDD:

  1. North BDD (xBehave) - The style Dan North and colleagues created and evolved and which is often seen as the given/when/then style. To me this style will be useful in bringing everyone into the requirements process and getting them talking the same language whilst providing a process to ensure that the requirements feed directly into development. In my view best suited to higher level testing and in particular to acceptance testing.
  2. Astels BDD (xSpec) - The style Dave Astels popularised and which, to me, is a new form of TDD which has some serious benefits. You can use this style for any testing, from acceptance testing downwards.

Some have argued that the given/when/then style is not needed, and that the xSpec style can be used for all levels of testing. I've tried this but didn't entirely like the results so I currently use both approaches because I actually think that using a different testing styles for acceptance testing and all other developer testing has benefits, particularly because the two types of test/specifications are quite different:

  1. Level - Although many of the BDD examples are against the domain/service layer level I actually think that in many systems you'll actually be using this style for your acceptance testing, probably from the top down.
  2. Language - Dan North makes a big deal of the fact that BDD can draw in the UL. I'm not so sure this is true because user stories aren't necessarily in the UL. However even if it is true it only applies to some of the specifications we're writing, namely those describe the user experience (acceptance level) and domain model.
  3. Reuse - When you're writing acceptance tests you've got a lot of potential for reuse so, in my view, composition wins out over inheritance. I'll describe this more in a separate post, to me, that's the biggest technical reason to look at xBehave (I just found out this is also Dan's view, see comments on this post).
  4. Tools - I'll cover this later but although I think you can do both styles of BDD without any tools I do think that Dan North's style is the one that will benefit more from additional tools/frameworks (such as NBehave) particularly if you are interested in people outside the development team writing the inputs and seeing the outputs (notably reports).
  5. Patterns - In my limited experience patterns/approaches that you come up with for developer testing don't necessarily scale up to acceptance testing where there is more reuse/complexity. I thus think that when viewing much of what is written about BDD you need to be clear on what type of testing the person is describing.
  6. Intent - Users/domain experts are only going to be interested in the behaviour of some parts of the system, notably the GUI and the domain so using the xBehave style right the way down is an un-necessary burden.

Its unfortunate that Astels and North both called their approach BDD, but thats the way of it. However we do need to get our terminology straight and that starts with understanding the differences between the two styles of BDD.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Sunday, July 20, 2008

BDD Talk by Scott Bellware

Greg Young has posted a link to a talk given about BDD by Scott Bellware which I highly recommend. I like it most because Scott clearly explains the differences between the two styles of BDD, one influenced by Dan North (*Behave) and one by Dave Astels (*Spec). I also like the fact that slowly but surely we're starting to use different terminology for the two types because mixing them up is (I believe) the cause of a lot of the misunderstandings regarding what BDD is all about.

My feeling, as I've posted before, is that both approaches have a lot of value but unfortunately the given/when/then style seems to me to be work best with some tool support (especially so you can parameterise the given/when/then itself) so it is harder to get into. I'm going to post more about my views on this later though.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Monday, July 14, 2008

NServiceBus - Getting Started Fast

NOTE: This post is probably only of interest to people planning to try out NServiceBus for the first time as the post is all about how to get it up and running quickly.

I've been trying to get up and running with NServiceBus because its relatively mature and has a good community and is based on good practices. However in my view quite  it is difficult to get into and there is a good chance you'll waste a lot of time time trying to get up and running so I thought I'd share what little I've learned so far with it.

I should also say that difficulty getting projects setup is fine, its a part of using open source projects. In fact although I love Castle and NHibernate both have a high barrier to entry, however in both cases there is lots of documentation available detailing how to get started with them so you never feel far away from an answer. That isn't the case with NServiceBus so I think that when starting out you need to make life easy for yourself. Anyway so far there have been two issues:

  1. Configuration - Out of the "box" NServieBus comes with Spring based configuration and someone has produced a Castle MicroKernel implementation. You also seem to be able to mix the configuration, doing some in code and some in the XML files.
  2. Referencing Projects - NServiceBus has a lot of projects. I'm not against that approach but since initially you have no idea what each project contains you do start off referencing just NServiceBus and two hours later you've ended up bringing in 10 projects. Just bring them all in to begin with and ignore the smell, you can sort it out later if you need to.

Anyway I go into a little more detail into these issues next, but you will probably also want to read this guide.

Referencing Projects

The DLLs I found I needed to reference:

  1. NServiceBus
  2. NServiceBus.Serialization
  3. NServiceBus.Serializers.Configure
  4. NServiceBus.Unicast
  5. NServiceBus.Unicast.Config
  6. NServiceBus.Unicast.Subscriptions
  7. NServiceBus.Unicast.Subscriptions.DB
  8. NServiceBus.Unicast.Transport
  9. NServiceBus.Unicast.Msmq
  10. ObjectBuilder
  11. ObjectBuilder.CastleFramework or ObjectBuilder.SpringFramework

Configuration

The "test\full" folder inside the solution has great examples of how to configure a client/server (see ClientServer and ServerRunner).

You still need to include the configuration file with the suitable elements in it, but examples of this are also included.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Monday, July 07, 2008

EF Team Blog - Data First

The EF team have a post on their blog about encoding logic into eSQL so it can be called in reports.

Not sure it's a good approach but at least you can give your opinions.

So far though I've completely failed because my comments on this and another post have not yet made it to the blog (they could still be waiting to be reviewed, but it has been over a day...).

Frustrating to say the least, makes me wonder whether I should just give up and stop looking at EF content altogether.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Sunday, July 06, 2008

WCF/Silverlight/IIS7 Configuration Links

I've just wasted 4 more hours getting my simple Silverlight/WCF play area setup.

I had lots of problems and although the answers were out there on the Web they were difficult to find, especially as SL/WCF seemed to be returning bog standard exceptions every time something failed. In particular I got sick of seeing "The remote server returned an unexpected response: (404) Not Found."

So here's a list of links that you might find useful if you are planning to play with SL.

Silverlight Links for Resolving Errors

Although google search was the main way I got answers I did find these sites useful:

  1. Forum - Plenty of gotchas and bugs in there to catch you out, solutions to my issues were available on here though.
  2. Irritated Vowel - Had some answers to issues I had, including cross-domain issues when calling WCF services.
  3. Tim Heuer - Looks like he's got answers to lots of issues you'll have.

Silverlight Config

If you are making cross domain requests ensure you have "clientaccesspolicy.xml" and/or "crossdomain.xml" setup and be aware that the required formats of these files is different in beta 1 and beta 2.

You may also get a ProtocolException (404 not found) when you try to call a WCF service. Cross-domain calls is one reason for this but another is that your WCF service is not setup for basicHttpBinding. You can read more on the forum or in Building WCF Services For Consumption From Silverlight. This page made me realize I needed to update my service reference after changing the binding. Lastly this forum entry pointed out that for it to work you need to specify that you want it to create a Website project to host the SL app.

Oh and you will also find that when you add a "Service Reference" to the WCF service you'll find that the "ServiceReferences.ClientConfig" is incorrect.

IIS7

I switched to using IIS 7 rather than the development server because I was having so many issues but to get my app within IIS7 I had to follow some of the steps here (important bit for me was setting it up for ASP.NET).

I then got an error containing the message "could not download the silverlight application". Turns out it was because the MIME type was not registered and the solution is to combine what is in this article with what is in this one (second one is more relevant).

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone

Wednesday, July 02, 2008

RESTful Web Services

I've been learning about REST for the last month or so and I quickly learned there was an awful lot of rubbish written out there, both supporting REST and bashing it.

Many of the REST guides that have been written just aren't that convincing. Luckily some of the more recent posts, including REST Anti-Patterns by Stefan Tilkov, are much better written and really look to be focusing on the details.

Anyway along with reading a lot of content on the Web I've been reading RESTful Web Services and I thought I'd write a quick review.

Essentially the book is well worth a read, it covers a lot of what you'll want to know about REST including fundamentals and some best early practices.

Some aspects of it did bother me a little. The first was that the code examples were mainly in Ruby, having equivalent examples in Java or C# might have been good. Secondly the examples focused on Web applications, for example a social bookmaking app written in Ruby on Rails, and I did feel an example of a more standard enterprise application might have helped.

Anyway I intend to give parts of the book a second read and I'd definitely recommend it to anyone wanting to know more about REST.

Share This - Digg It Save to del.icio.us Stumble It! Kick It DZone