I have been using SpecFlow with WatiN for about 9 months now. It's a great combination for driving the features you want in a web site and verifying they work as expected. SpecFlow takes care of the BDD framework and application features side, while WatiN drives the browser to verify behavior.
I've gotten used to the the pattern of writing a SpecFlow scenario, then writing the WatiN code in the step definition to open a browser and perform the task or look for the expected HTML. Once you get the hang of the tools and the process, it's a very sustainable workflow for the developer.
But today I ran into something that I couldn't test with WatiN. I wanted to check that an XML sitemap was coming up correctly on a web site. WatiN was able to open the XML document in the browser, but there was no Body tag because the XML is not an HTML document, so WatiN couldn't read the XML. All I needed to do was verify that an expected value was in the XML sitemap. If the value was found, the test would pass.
I spent about 15 minutes trying out different WatiN commands to find the text, but with no Body tag, there was nothing loaded into the WatiN object model, so nothing was working. I also tried looking through the WatiN Elements collection and a few other dead ends, but it was only showing me the previous web page or null.
Finally, the obvious answer occurred to me. I'm looking at an XML document and I want to verify that it has a value in it. I'm in a SpecFlow step definition and I've got the entire .NET framework at my disposal, not just WatiN. Five minutes later, I've got it coded to load and examine an XDocument for the value I needed so the test can pass.
This was a good lesson for me. Being on a development workflow roll is no excuse to not keep your head up for alternative strategies that would better solve your problem. SpecFlow isn't just a wrapper for WatiN calls. It can be used to verify any behavior it can invoke.
