Category Archives: Watin

Debunking Anti-WatiN bullshit marketing from SWEA

Posted on by
3

In a previous post, I talked in a closing comment about how some tool vendors are trying to piggyback on WatiN to promote their inferior tools. Well there have been a couple of comments on my blog since from SWEA evangelist, Alex at a Hotmail address.

SWEA is much better product than WATIN. It can save days on test development and maintenance. Any small UI change will require change in the WATIN scripts, but SWEA scripts are more resilient to the UI changes – the control binding is separated from the script code. WATIN is just thin wrapper around HTML DOM, but SWEA is complex automation framework.

You can also try SWExplorerAutomation (SWEA) from webiussoft. SWEA is not free but provides more functionality (Recorder, Data Extractors, internal support for AJAX, more resilient to UI changes scripts) than WATIN.

Ok first things first. This is my blog and not a public forum. If you want to advertise on my blog, you can pay for your adds via Google. It is for this reason that I have deleted these comments.

Let’s debunk these claims one at at time.

Claim #1 SWEA is much better product than WATIN.

Dictionary.com defines a product as “the totality of goods or services that a company makes available.” WatiN is free and not produced by a company. So I will concede that point SWEA is a better “product” than WatiN, simply because WatiN is not a product at all.

Claim #2 SWEA scripts are more resilient to the UI changes … any small UI change will require change in the WATIN scripts

Now that is complete BULLSHIT. Good script design and development practices have significantly more impact on how resilient a script is to UI changes than the underlying tool does. WatiN supports controls defined as .net regular expressions. Using WatiN Attributes in a control class, allows controls to be defined in a single location and called consistently regardless of how WatiN finds the control. Couple that with Visual Studio 2005′s refactoring support and I am working in UI change nirvana with WatiN. If anyone needs to know how good script design should be done, please feel free to follow my blog post series and learn how to do it properly.

Claim #3 SWEA is not free …

That one is true.

Claim #4 SWEA is not free but provides more functionality (Recorder, Data Extractors, internal support for AJAX …

You can get WatiNRecorder from here, so that is an outright lie.

I honestly don’t know what a “Data Extractor” is, nor why I would need one.

WatiN does support AJAX, and yes there are some issues, however they are well know and being improved every day, so that is another lie as well.

Claim #5 WATIN is just thin wrapper around HTML DOM, but SWEA is complex automation framework.

WatiN is a thin wrapper around Internet Explorer, not just the HTML DOM. One of the key reasons WatiN and Watir do so well are their elegance, simplicity and speed. I personally would not be quoting complexity as a feature or any application.

Honestly, SWEA may be an OK product, however if it was so good, webiussoft wouldn’t need to leave comments on every WatiN related blog post they can find, pleading for people to try their products instead.

I’ll leave the last word on this to a comment one one of my posts from Petey in regard to test tool companies that resort to blog spam marketing : “Don’t forget SWEA. It is so annoying!”

If that isn’t a great reason to not try a tool, I don’t know what is.

Building a GUI test automation framework: Structuring the project

Posted on by
1

This post is the third in a series of posts, building a GUI test automation framework. In the first post, I outlined the key design goals of an automation framework. In the second second post I talked to the need for a control file. Since the original posts way back in early 2006, a lot has changed. As a result I am going to re-focus (and finish) these posts on how you can structure and develop a set of simple tests using WatiN.

Ok there are some pre-requites if you want to run these examples. I am going to assume that you are running Visual Studio 2005, SQL Express 2005, nUnit 2.4.0 and we are using the asp.net job site starter kit as our test application. I was planning to use the .net petshop 4.0 for this article, however it wouldn’t install with Windows Vista.

Ok assuming you are up and running, let’s get started.

The general structure that I like to follow for this type of project is to have a single solution broken up in to several projects. The standard projects that I like to have are Controls, Framework and Tests. In this example I am also going to add a fourth project to hold the site URLs.

Once I have these projects in place I set up the classes so they are all using single namespace that is then subdivided in a similar fashion such as: JobSite.Controls, JobSite.Tests and JobSite.URLs.

You can download the solution with the basic structure from here. I have set up a Codeplex project http://www.codeplex.com/WatinJobsiteSample/ to store the source code for the examples in the rest of this series of blog posts. In the next post we will get seriously back on track and start putting our test framework together.

Open source test tools are the way of the future

Posted on by
9

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 !

Using regular expressions in WatiN

Posted on by
Reply

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 …