Catching server errors with WatiN

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:

Conclusion

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:

• A clear indication of the real problem instead of the more verbose ElementNotFoundException stating that it couln't find an element on the page.
• Information about the "Server Error"
• Early failure of the test  because the ServerErrorException gets thrown even before WatiN start looking for the element which isn't there and finally times out.

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.

Tags van Technorati: WatiN