Archive for the ‘TDD’ Category

Go Watin!

February 14th, 2007

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.

Selenium is either brilliant or a big hack. Possibly both. It starts its own web server, and starts the selected browser to access it. From there it can “command” the browser through javascript to invoke things on your app’s DOM.

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!

Categories: TDD | Top Of Page | 5 Comments » |

First experience with MbUnit and Watin

January 2nd, 2007

During the last two days I’ve completed a project for Castle Stronghold’s client. The project was a complex sign up wizard, built with MonoRail. It involved plenty of javascript validations and ajax calls, and it was a pain no to have automated test cases. So to speed up the process I decided to create a very minimal set of tests and give MbUnit and Watin a try. Usually I’d do it with Watir.

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:

[ProcessTestFixture(ApartmentState=ApartmentState.STA)]
public class IndividualRegistrationTestCase : BaseWebTestCase
{
	[Test, TestSequence(1)]
	public void StartWizard()
	{
		ie = new IE(urlBase + "/registrationindividualwizard/start.win");

		dialogHandler = new SimpleJavaDialogHandler();

		ie.AddDialogHandler(dialogHandler);

		...
	}

	[Test, TestSequence(2)]
	public void FillStep1ForIndividual()
	{
		Assert.AreEqual(urlBase + "/registrationindividualwizard/BasicInformationStep.win", ie.Url);
			
		...
	}

	[Test, TestSequence(3)]
	public void FillAdditionalInfo()
	{
		...
	}

	[Test, TestSequence(4)]
	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

Assert.AreEqual("red", ie.Element("labelmsg").Style.Color);

Another thing I didn’t like was

ie.SelectList("data_city").Select("");
ie.SelectList("data_city").SelectByValue("");

You can guess that the Select will use the text by exclusion. Why not use SelectByText then? The following also doesn’t look good:

Assert.AreEqual("SP", ie.SelectList("step2_State").SelectedItem);

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!

Categories: General, TDD | Top Of Page | 9 Comments » |