I've wanted to post about using Selenium and TeamCity to build and test .NET websites on Windows for a while.
Unfortunatley it hasn't been forthcoming as I only really use Windows/.NET at work these days.
I decided I would get my shit together today and write, what may be my last post on .NET for a while,
in response to @DavidBurela's Developer Blog Banter topic
"How do you test your applications?"
I'm going skip unit-testing (which we do and try to get better at), BDD and JavaScript testing (which I would like to do and get better at) and focus on automated browser testing.
The Build Process
Watching automated test may be fun the first few runs, but it won't last long.
Anyway if you want automated browsers tests, surely you want to automate the automated tests, right?
The build process is going to need to automate the browser and run the site the browser is browsing.
For this we use IIS which is scriptable with the PowerShell WebAdministration module (maybe I will write another post on .NET).

The problem with having the UI Test step in this sequential process is it very quickly starts taking ages.
This sucks; I want feedback as soon as possible.
TeamCity provides feedback after each stage, but we don't get our green light.
This could be resolved by putting the UI tests in a nightly build, but I think a staged build or build pipeline is usually better.
The first stage compiles, runs unit tests and produces a deployable website as an artifact, this process is hopefully quite fast.
If the first stage is successful the next stage in the pipeline is triggered which runs the less timely integration and UI tests.
With a build file that has appropriate build targets setup, this build pipeline can be setup in the TeamCity administration web interface.

If you want to get awesome you can also start using Selenium Grid to distribute test agents or use a cloud based solution like SauceLabs
Tools
Our automated build process consists of a few tools.
TeamCity for our build management and CI server.
After years of using CC.Net and a very brief and painful exposure to TFS, I love TeamCity.
I also hear great thing about Hudson.
NUnit and included NUnit-Console. It does what I expect a unit-test framework and runner should do.
MSBuild with the MSBuild Community Tasks for our build scripts.
I have to have some sort of build script to do continuous integration in .NET when not using TFS.
I would like to be using a modern scripting language or DSL instead, but MsBuild is doing the job for now.
Selenium for our browsers automation tests. It has a recorder, a server which does the brower automation and can be controlled from by
.NET client library.
Creating Tests
Selenium IDE is a Firefox plug-in for recording and running tests.

Selenium IDE is pretty slick and importantly it's a tool non-developer-testers-types can quickly get their head round and start producing some tests.
What we really want though, is to have our tests in code so we can run on them on build machine and version them in a repository.
Test Scripts

That should generate something like this.

This generates test files you can pretty much just add to your project as NUnit tests.
This also means automation tests can be run by the nunit-console just like unit tests.
The .NET client drivers are in the Selenium Core download.
It may be worth considering if exporting these tests to C# ideal.
Keeping them in the standard html table based form means they can be reloaded into the IDE,
and there are also alternate languages that you can export to.
Selenium Server
Selenium server runs on the JVM - Yep, suck it up. TeamCity does too :)
Any standard version of Java should be fine.
If you've installed Java correctly it should be in your path and you should be able to type this in a console.
c:\>java -version
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing)
This should output the Java version and build information. If so you have successfully installed a java runtime. Yay!
You need to download the Selenium RC and extract the selenium-server.jar file.
Once you have Java and Selenium Server you should be able to start the server from the command-line.
java -jar selenium-server.jar
Selenium Server as a Service
I wanted to run SeleniumRC (the same Jar) as a service. Console windows on servers are not so cool.
Another, probably better, option is to have the build script itself start and take down the server.
I went with the service option.
I found a solution for running a .jar as a service, but it didn't work on 2k8.
Luckily that lead me to the Non Sucking Service Manager which has a great name and worked fine.

The parameters I used were "-Xrs -jar [path/to/selenium-server.jar]"
Discussion
I went down the path of browsers automation because I was finding none of our other testing efforts, while valuable,
were not actually testing the website would work.
Despite our best efforts we were still have problems where a page or an entire site would return a HTTP 500 Server Error for many reasons.
- Code problems a unit-test would ensure the fix.
- IOC or ORM/Database configuration.
- Compilation error at runtime on a JIT compiled view page.
- JavaScript Ajax.
Anyway it happened for all types of reasons. What we needed was an end-to-end integration test. Browser automation provides these tests, and it has helped.
I actually don't see the tests themselves as being particularly fragile.
No doubt they can be, but I think it also encourages clean markup.
If the hierarchy or attributes change then UI tests are not the only thing that will break.
Stylesheets, scripts and some server logic also depend on it.
While I have seen good value from browser automation testing,
I feel that mocking out the entire web framework (like NoseGAE for AppEngine)
or testing at HTTP level (which I think is what WebRat does for Rails) can test almost the same thing without involving browser autmation at all.