Kanbanboards III–putting on the web

· January 23, 2011

After my latest post-of-admitting-failures I got some really nice feedback from a lot of people. Apparently there are others out there who think that a failure is a great learning opportunity. OK – I will most certainly continue down that path.

I actually write these posts as I code along. It’s forward only mode in other words… Almost.

Comments

One of the nicest things that happened as a result from the last post was that Darren Cauthon gave me some insightful comments and patches to go with them. This “social coding” that is going on, on www.github.com (a.k.a. programmers Facebook) is really, really cool.

Darren has done a lot of stuff in and around the SpecFlow project, for example the SpecFlow Assist (table helpers) that is really great. So I value his opinions a lot. He gave me 4 points to think about and I thought I’d comment on them here as I learned a lot from them and think maybe you will too:

  1. Line up your SpecFlow tables correctly. This is a great point that will make the feature-files be readable outside Visual Studio. I think that the readability is a key feature of BDD so totally agree there. Committed!
  2. Don’t use asserts in the When-step. Totally agree on this! The Given/When/Then mantra is from the outset a development of the Arrange/Act/Assert. Don’t assert in the act step seems reasonable and gives you a better separation of concerns in your step definitions. Committed!
  3. Split your step definition files into files per thing or concept. Great tip! Didn’t think at all of that – but it makes a lot of sense and also pushes me to think about keeping the steps clean from state and other smells, so they can easily be stitched together in other scenarios. Committed!
  4. Use SpecFlow 1.5. I actually thought of this the moment I realized that NuGet didn’t give me the latest version of SpecFlow. There are some great additions to SpecFlow, especially the one Darren mentions. So I guess I’ll go manual and include SpecFlow 1.5 myself. Or maybe I can upgrade the NuGet-version of SpecFlow? Committed!

OK – with the aid of GitHub and not to mention Darren, the project is now in great shape.

But really - it’s just too hard to grasp git sometimes. I finally applied Darren’s changes as a patch. I am a damaged Microsoft developer who hasn’t adjusted to the bash/dos command only world of git.

On with tasks at hand.

Updating the specs for the Homepage

The current scenario lacks a little bit of information. When you navigate to the homepage of the application, you should not only see the top three favorited Kanban boards, there should also be a list of the newest additions. The simplest way to do that is simply to augment the current scenario with a new Then-statement. Like this:

updated scenario

The observant reader sees that I’ve done a few minor tweaks to the scenario title and the When-step as well since it didn’t fit or read very well.

OK – this of course fails since I haven’t implemented the step yet. Yada, yada, yada – it’s all been explained before. Finally, led and driven by my scenario, I ended up with this new When step definition:

then step for latest additions

And this, rather ugly, action method for the Index action of the KanbanBoard Controller:

updated index action method

Let me be the first to acknowledge the possibilities for improvement here. I was thinking of using CQRS as my architecture for this application, but didn’t because that would be too many things at once. I might go back and redo the application CQRS style as an exercise to learn it later.

Right now I’m satisfied with this. It keeps my focus on the stuff I wanted to learn and the scenarios will be a great guide when I redo the architecture later. Wow – I’m looking forward to it already.

Let me also here declare my standpoint on TDD and Scaffolding (see this). OK – I’m going to treat the generated repository code as not mine. I actually added the DebuggerNonUserCode attribute to the repository, until I need to change it. The rest of the code will be touched on and hence tested, even though I sense that it will be much more BDD than TDD.

Writing an end-to-end acceptance test

Right now the application doesn’t work if you actually run it. That’s one of the drawbacks of writing your step definitions against the controller level of the application. The gain is that you get faster test execution (NOT to be underestimated) and also a much faster writing experience.

But I sure want the application to work. So I will have a few integration tests that will run end-to-end – from the HTML down to the metal in the SQL database.

Since I haven’t yet, this process will force me to install an IoC Container (Ninject baby) and to set up and configure the database (SQL CE which looks nice… and is free). NuGet will do the heavy (?) lifting for me. And the scenarios will guide me.

Writing the scenario

I have created a new project for the acceptance tests (called… AcceptanceTests). The difference from the specs in the Specs-project is that these tests will test a whole application and be handled separately. I will use tags to distinguish slow end-to-end tests from fast specifications.

Testing an entire application forces you to think about loading known test data or writing scenarios that are less dependent on test data.

Here is the feature file for the acceptance test:

first acceptance test

I started to implement the steps for this scenario – which failed with an inconclusive status as expected. I created a step definitions class for the home page, but expect that other pages will require their own classes.

For browser automation, I’m using WatIn. It’s not available on NuGet, so I had to download and add it manually. I also used Steven Sanderson’s browser wrapper.

Here’s the step definition for the first implemented step:

acceptance feature

When running this, I encountered the “yellow screen of no Dependency Injection controller set”:

yellow screen of missing DI container

I needed a Dependency Injection framework. Luckily, Ninject has an MVC 3 version that I included using NuGet. Here’s how I registered the KanbanRepository:

ninject mvc injected

Ninject is now installed, and NuGet is a great help.

More errors – database integration

The next problem I faced was that the model returned was empty because the database was missing. I resolved this by following the steps outlined in Scott Gu’s blog post. After installing Visual Studio 2010 SP1, I could open the database and add some data.

I encountered another issue: “model doesn’t implement”…


Note: The content has been truncated here. Make sure to adjust or complete based on actual content needs.

Twitter, Facebook