Category Archives

Watin

Open source test tools are the way of the future

As you can tell from my blog, I am a big fan of WatiN. One thing that WatiN doesn’t do is test non IE stuff. Well as part of .net 3.0 Microsoft has now shipped API’s that allow testing of Windows apps, including both legacy Win32 and WPF applications. There is an MSDN article on how to do this here.

So what does this mean? It essentially means that commercial tools are dead in the long term. If it is possible for a single developer to build tools that work better than commercially available tools costing hundreds or thousands of dollars, which it currently is. It won’t be long until they are not purchased any longer.

Another interesting phenomenon is that companies are trying to advertise their tools by adding comments to blogs, such as this one saying things like, you should try tool xxxx.

Sorry but when your commercial tool costs more and does less than the open source alternative, it is time to look for a new product to develop.

Another major irony is that if the open source tool has a bug, or doesn’t have a feature I need, then you can simply open up the code and fix it or add the feature. Most commercial vendors take 4-6 months or more to investigate, test and resolve issues.

So if you haven’t yet, download a copy of WatiN, WatiNRecorder, nUnit and C# Express, then see what the future is like and join in by submitting back features.

One final word, Webiussoft and Inscif, please stop trying to promote your commercial tools by adding comments to blogs about WatiN, we aren’t changing !

Testing Watin9 comments

WatiN Recorder

Richard Griffin has ported WatirRecorder++ to work with WatiN. For more details please visit the post on Richard’s blog.

Testing Watin0 comments

Using regular expressions in WatiN

Anyone that has done any serious test automation of ASP.NET applications knows that .NET is a tad verbose when it comes to the control names that it generates. ASP.NET generates its control ID’s based on a hierarchy of controls. For example, if you have a textbox inside a user control that is placed in side a placeholder, the of name property of the control will be something like name=”ctl00$ContentPlaceHolderMain$UserConrol1$txtLogin”. On some applications I test, I have seen control ID’s 130+ characters in length. This presents an interesting challenge to the automator where your scripts can easily become something like this:

ie.TextField(Find.ByName(ctl00$ContentPlaceHolderMain$UserConrol1$txtLogin)).TypeText(“Bruce McLeod”);


There are two scenarios that we want to be able to easily handle to maximise script maintainability. Firstly, if the control is renamed, we only want to have to change the control in one place. Second, if the hierarchy of the controls is changed, (or if the control moves in the page) we want to be able to handle it easily.

One of the new features introduced into version 0.8 of WatiN is support for using regular expressions. This provides a extremely powerful way of solving both problems.

The first thing we will do is define a static class that returns the name property of the control. If this control was being used to test, say Amazon.com, I would structure the class that uses a namespace structure that allows the use of intellisense to help find controls at design time.

using System;

namespace Amazon { class LoginPage { public static string txtLogin = "ctl00$ContentPlaceHolderMain$UserConrol1$txtLogin"; } }This allows the test script to be simplified as follows:

ie.TextField(Find.ByName(Amazon.LoginPage.txtLogin)).TypeText(“Bruce McLeod”);


Ok problem one solved, and now that we have our class, we can easily change it to use the regular expression support. If we want to ignore the whole control hierarchy and only match the control name txtLogin, then we can use an expression like:

[a-zA-Z0-9\$]*txtLogin
(If like me, you can never remember what the expression should be, I can highly recommend regexlib.com, which contains examples, reference sheets and a regex tester.) WatiN implements overloads in Find.ByName and can consume the control name as either a string or a Regex. This allows us to use the regular expressions by only changing how the control is defined in the class. An updated version of the class using regular expressions is as follows:
using System;
using System.Text.RegularExpressions;

namespace Amazon { class LoginPage { public static Regex txtLogin = new Regex("[a-zA-Z0-9\$]*txtLogin"); } }Now the only thing that will cause us problems is if the txtLogin control us renamed, or another txtLogin control is added to the page somewhere else. But what are the chances of that happening …

Testing Watin0 comments