Bird Stream

UI Integration Testing with CassiniDev and WatiN, not Selenium

This was to be my first foray into UI integration testing. I've always been a sceptic, scare by the brittleness of any kind of recorded UI test. Luckily Gemma and Jonathan in the dev team persisted and showed me Selenium RC and WatiN. Both these solutions allow you to write the integration tests in code, a critical requirement for me.

Also key for me was this had to work in Hudson, my chosen Continuous Integration server, so simple deployment and management was key. I love being able to check everything I need into source control and have it 'miraculously' run on the CI server with little or no config.

The first thing I needed was a deployable web server I could, ideally, run in process. Enter CassiniDev and specifically the CassiniDev4-Lib.dll. Now this was really tricky to get going ;).

1. Add reference to CassiniDev4-Lib.dll

2. Put following code in my TestFixtureSetup

_hostServer = new CassiniDevServer();
_hostServer.StartServer(@"..\..\..\mywebapp");

Selenium wasn't quite so simple.

It failed the simple deploy requirement because you have to run the Selenium Server and then use the RC libraries to interact with it and send commands to then run on browsers.

It also has/d a bug where it sends a HEAD before it sends a GET which breaks if your MVC Controller Action as an HttpGet attribute. It sends a 404 because HEAD isn't acceptable.

Sky from the CassiniDev team was über-helpful finding this out for me http://cassinidev.codeplex.com/Thread/View.aspx?ThreadId=227174.

WatiN was a different story though. Very simple to use and all run in process. There were a couple of gotcha's though.

I had to make sure NUnit was properly running .net 4, stackoverflow helped me there http://stackoverflow.com/questions/2635794/nunit-fail-with-system-argumentexception-the-net-4-0-framework-is-not-available

And I got a rather gruesome COM exception when I pushed it all up to my CI server. 

NSystem.UnauthorizedAccessException: Retrieving the COM class factory for component with
        CLSID {0002DF01-0000-0000-C000-000000000046} failed due to the following error: 
        80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
    at WatiN.Core.IE.CreateNewIEAndGoToUri(Uri uri, IDialogHandler logonDialogHandler, 
        Boolean createInNewProcess)
    at WatiN.Core.IE..ctor(String url)

Luckily I found this post that talks through setting the COM permissions correctly for this kind of issue. Specifically giving the correct permissions to the user account used by the Hudson server. How To Fix UnauthorizedAccessException Retrieving The COM Class Factory For Component With CLSID

Early days, but I now have a green build that includes actually navigating to one of my forms and entering text within an integration test.

Selenium seemed to be the obvious choice for UI testing. I read somewhere that Google is throwing loads of effort into developing it so it would be a good horse to back. However, when I look at my requirements I don't need what Selenium offers.

Multi, cross-browser testing is nice but I'm just looking to confirm stories are operational and routes through my application are valid. The simplicity of WatiN seems to satisfy that nicely.

ASP.NET MVC2 Wildcard Mapping on IIS6

Spent a little while tearing my hair out on this one. I followed Steve Sanderson's post ( http://blog.stevensanderson.com/2008/07/04/options-for-deploying-aspnet-mvc-t... ) but I was still getting the classic IIS 404

Finally found the answer in the Web Service Extensions section of IIS Manager. I had to enable the ASP.NET v4 extension

But just clicking Allow here didn't work. I actually had to go to Properties > Required Files and Allow the aspnet_isapi.dll.

Sorted

One of my favourite features of the new office

Office coming together

A big few days to get it all done but we move in here on Monday.

There's no mistaking where you are.

How we laughed!!!

A DVCS working process

I've started working with Git using GitHub as a remote repository. This introduces into my life branching as a cheap operation and makes for a potentially different way of working.

After a discussion with the guys at work on Friday afternoon, here's what I've come up with:

Start a new feature => start a new branch.

git branch master [feature branch name]

The master branch is preserved for the current release code. My Hudson instance is only monitoring that branch for changes and ignoring all other branches.

I then push the branch to my remote repository so I get the benefits of a back-up as well being able to share the branch if I need to collaborate with someone else on it in the future.

git push [remote repository address] [feature branch name]

The code rythym then becomes add files, commit to the branch and then push to the remote repo branch.

Once the feature is finished then it's a case of squashing the commits on my local master branch and then pushing them to the remote copy.

git checkout master

git merge --squash [feature branch name]

git push

Then it's just a case of deleting the feature branch when I'm happy it's complete

Would appreciate any thoughts on this, does it sound sensible?

Test teams are pointless and counter-productive

In an Agile world unit tests and integration tests, in our case driven
by BDD declared stories, are a fundamental part of a development
team's output. It could be argued that this is the most important
element as these both prove the software works and document what it is
supposed to do.

Coverage is key to the success of this. The developers need to ensure
their tests cover sufficient scenarios so as to ensure the software
delivers when used in anger.

The traditional approach is to have a dedicated test team that checks
the code in isolation as developers 'can't be trusted' to do it
themselves.

Personally I think this is balderdash.

The test-team-as-gatekeeper approach encourages a lack of
responsibility in the development team. They can produce what they
like, safe in the knowledge that the test team will pick it up. And,
if they don't, well they're mainly to blame rather than the
developers. After all, they're not testers.

Far better to have developers engaged all the way to delivery and beyond.

Pair programming, peer reviews and giving rapid iterations for the
customer to critique and break all ensure the coverage is complete.
But there is nothing like actually engaging with the user to really
bring home the importance of the feature being worked on or to bring
in to stark relief the usability assumptions they've made.

So, death to test teams. There is no place for them in an agile world.