I’ve seen many selenium related posts recently and Henry and I thought it was a de-facto standard product to use for UI TDD and acceptance tests. We decided to embrace it to create tests for an existing functionality, to reproduce a bug we knew was there and had to be fixed, and to TDD a new feature.
We didn’t like it. We just didn’t like it at all. The API wasn’t intuitive, every parameter is a string. It took us too much time to find a method as the API is basically a flat bundle of methods.
So we rewritten everything to use Watin. We’ve seen code being reduced, the API is a gazillion times better (I tend to exagerate), and the test run faster. There is room for improvements, though, but as a nice open source project they accept patches through the mailing list (and we are working on improvements)
If you’re new to Watin, check Web Application testing in .net.
Update: Chris Ortman pointed me to this blog entry. Really interesting!
First, MbUnit is nice. I liked the different kinds of test fixtures offered by it, and used the TestSequence a lot. However the project lacks something I find important, which is the API documentation. I usually get to know more of a project by simply navigating the namespaces on Object Browser. Most of attributes, classes and asserts were not documented (except the standard set). I also dislike the wiki-style documentation, but I understand that this is the easy way to maintain a documentation. The problem with this kind of documentation, which btw Castle used to have, is that it does not take the user by hand and teach about the project in small steps.
Another thing I liked about MbUnit was the report generated. It is damn clear about what has failed, be it a SetUp/Teardown, which is something the NUnit lacks. This support alone is enough to make me adopt it right away.
My test sequence was:
public class IndividualRegistrationTestCase : BaseWebTestCase
public void StartWizard()
ie = new IE(urlBase + "/registrationindividualwizard/start.win");
dialogHandler = new SimpleJavaDialogHandler();
public void FillStep1ForIndividual()
Assert.AreEqual(urlBase + "/registrationindividualwizard/BasicInformationStep.win", ie.Url);
public void FillAdditionalInfo()
public void FillBankInfo()
The runner for test sequence also doesn’t detect if a sequence number is repeated, this happened due to a stupid copy & paste…
So MbUnit guys, you’ll have to invest some time on the API docs and producing a nice documentation/web site. For more on this, check the book Producing Open Source Software.
Now Watin is cool. It works just like a Watir and they seem to have tried hard to mimic the niceness of the API exposed by it. I couldn’t test different attributes, like style, though:
string val = ie.Element("labelmsg").GetAttributeValue("style");
This fails with an invalid cast exception. For me, asserting the style is important as a way to check whether the JS validation is working for invalid values. It would be great if the style could be an object, like
Another thing I didn’t like was
You can guess that the Select will use the text by exclusion. Why not use SelectByText then? The following also doesn’t look good:
It’s not clear whether SelectedItem will return the text or the value selected. It could expose two variations, SelectedValue and SelectedText which would make it a little bit better.
Anyway, both projects are ready to rock. Increasing the adoption will quickly solve these minor problems as long as they encourage people to send patches/contribute. So hurray, the .net OSS community is finally thriving!