If you like the way NUnitAsp handled things this might be one for you. WebUnitAsp (http://dotnet.org.za/colin/archive/2008/04/22/webunitasp-2-an-experiment-in-unit-testing-asp-net.aspx) is a wrapper around the WatiN API and gives you the look and feel of using NUnitAsp. This version of WebUnitAsp is based on the WatiN 2.0 CTP.
Update 9/18/2009: The described solution described below no longer works as of WatiN 2.0 beta 1. See this blog post for the new way.
Going through the WatiN bug tracker on SourceForge I came along this bug report:
"When you retrieve a Table Row that contains TH elements, the TableCells collection returns empty. The reason being TableCell only recognizes TD as a valid tagname, when it should recognize TH."
I agree that TH elements probably should be seen as a TableCell as well. I'm a bit reluctant though to fix this because this will change the behavior of WatiN possibly resulting in unexpected failing tests for users of WatiN. So I did a small experiment to see if you (as a user of the WatiN API) are able to make WatiN handle TH elements as a TableCell if you need it to.
First I created this HTML table for my test
Next I wrote and ran the following unit test and..... it passed!
The trick is in the line:
TableCell.ElementTags.Add(new ElementTag("th"));
This registers the TH element as an element that can be wrapped by the TableCell class.
I tested this against the current development code and it run just fine. It probably will work as well with the current 1.2.1 and 2.0 CTP releases.
I'm finishing of the last bits before the release of WatiN 3.5. Recently I have added support for .Net 3.5 specific features. Following is a screenshot of some of the tests. As you can see:
I have done some speed tests on both and performance is just as good as when using the "old" Find.By... syntax which uses AttributeConstraints and Comparers internally.
I'm finishing the changes to use lambda's this week. The changes to support Linq are already committed to the SVN repository on SourceForge so you can check that out if you can't wait until the release of 1.3, which won't be long btw.
One of the main benefits of testing through the web browser is that you are testing everything related to the creation and rendering of the HTML. Even if you use the Model-View-Presenter or Model-View-Controller patterns and have unit tests for the model and the presenter(s), the view is still hard to test without firing up the web browser and seeing the actual page. At my daily work we use the MVP pattern with .Net ASPX pages so we can test most of the UI logic without having to fire up a browser. Still there is a need to test the UI using WatiN cause there are things which can't be tested in any other way.
Occasionally tests fail with an ElementNotFound exception. When investigating the problem the problem had nothing to do with a misspelled element id or something alike, but it was caused because of a "Server Error". The well know ASPX Server Error page was shown, giving you the exception message and the stack trace. The ElementNotFound was thrown because WatiN was looking for the element on this (unexpected) Server Error page.
Wouldn't it be nice if we would have a more accurate exception instead of the ElementNotFoundException and also have all the information shown on the Error page available after the test has failed? You can do this with WatiN and I will show you how.
First we need to create a class which inherits from the WatiN.Core.IE class, let's call our class MyIE for this example. We will use this class in our tests instead of the IE class.
Now that we have this class in place, we need to add a hook to check if the "Server error" page is shown. A great place to add this is the WaitForComplete method cause every action executed by WatiN on your page which could lead to a postback to the server will call this method. So the GoTo(url), the Click() on a button or the TypeText() on a input element (and many more actions) all call the WaitForComplete method to make sure any further action is postponed until a possible postback has returned its result.
Knowing this, we can override the WaitForComplete method, call base.WaitForComplete and than check for the text "Server error" on the page. Here is the code:
This is an example of a test using the MyIE class.
And here is how a failing test result due to a "Server Error" looks in ReSharper:
Creating your own IE sub class gives you the possibility to improve the information you get from a failing test due to a Server Error. In this case the ServerErrorException gives you:
Using this pattern of inheriting IE in your own class gives you many more options. In one of my next blogs I will show you how you can utilize this to tweak the performance of WatiN.