A short shout out to announce the release of WatiN 2.0 Release Candidate 1.
Many fixes and new features since the last beta 1 release way back in March. I’m still compiling the list of changes so check back on this page later this week. But if you follow my blog you are well informed already. If you haven’t been using beta 1, start reading the release note of that release here.
And of course you want to download the new release.
Enjoy testing with WatiN!
Update 18 December 2009: Added missing file to code download
WatiN is all about simplifying the way you can interact with a web browser and the elements on a page. Simple elements are just wrapped (like divs, links and alike) but for more complex elements WatiN offers you functionality which hides complex interactions with the browser. For instance TextField.TypeText will not only set the value of an input field but will also fire all the appropriate events, basically simulating a real user typing in text.
But what if you want to automate/model some action that involves complex logic and/or multiple elements. Yes indeed I am referring to all those ASP and third party controls out there. In this post I will show you how to create your own control which you can use as if it is an element on the page and natively supported by WatiN.
You can download the code for this post here (which also contains a build of WatiN 2.0 RC1)
| I’m going to show you how to create a basic control for the jQuery UI Datepicker. But that’s simple you might think, just use TypeText of the TextField class, the WatiN wrapper for input elements of type text. True, but then I need to think about formating the date correctly every time I automate a datepicker. And there might be other things I would like to check on the datepicker (see jQuery-UI Datepicker for all the options that can be set and read on this widget). So I’m going to use the javascript API of the datepicker to automate the control. |   |
Wondering how to use this control in your test code?
Looks familiar (and simple) doesn’t it.
To create the control I need a root WatiN.Core.Element subtype which will be the base/root Element for my DatePicker control. Since a html input of type text serves as the root element for the jQuery UI datepicker widget, it makes sense that DatePicker will use TextField as its root Element.
Since I decided I’m going to use the datepicker’s javascript API, the control needs to execute scripts inside the browser. Fortunately WatiN offers this functionality through the RunScript() and Eval() methods, both exposed by the DomContainer class. Control<T>, the base class for every control, exposes the property Element which returns the root Element of the control, in this case TextField. From there we can get to the DomContainer to execute javascript using Eval().
Next thing to do is to create the javascript to set the date using the API of the jQuery datepicker. This is what the script needs to look like to set the date to 10 December 2009 (indeed the month is 11, a javascript thingy):
window.jQuery(element).datepicker(‘setDate’, new Date(2009, 11, 10));
To make sure that the javascript references the correct html element in the DOM, I will make use of the new method GetJavascriptElementReference(), available on every (subtype of) Element (in WatiN 2.0 RC1). And of course the Date should be created correctly.
I’m also using window.jQuery() instead of window.$() to make sure this script will also work when $() is not a shortcut for the jQuery() function (but instead is used by some other javascript library like Prototype).
I will combine all this in the setter part of the Date property of the DatePicker control:
For the getter part there is one catch, transforming the returned javascript date in to a DateTime instance. Fortunately DateTime.Parse parses a UTC date format without any problem, so I let the javascript return the date in such a format.
Now that we can set and get the date of the jQuery UI Datepicker widget we can start using it in our tests. And it offers a create place to add more functionality.
I hope this post will help you start creating controls for your own or third party controls. There is much more that you can do so check out the download with this post to see:
There is also a WatiN-Contrib project started on Google code. So if you like to share your third party WatiN control library, let us know.
Enjoy testing with WatiN!
Of course you can scrape web pages with WatiN so why this blog post you might ask. Well, with the out-of-the-box WatiN browser support you need to instantiate a browser to get the HTML for a page and scrape it. If you don’t need to interact with the page, like clicking on links, type in some text or rely on cookies for session state, you don’t need all the overhead (memory, start up time) of the browser.
This article will show you how you can use WatiN browserless by implementing a new browser: MsHtmlBrowser, using techniques described in this article.
For this code I use the current development code which will soon be released as WatiN 2.0 RC. You can download the code for this post here.
The trick to make this work is to make use of IPersistStreamInit and HTMLDocumentClass.
First lets get the definition of IPersistStreamInit in place:
And this is how we can combine it with the HTMLDocumentClass (don’t forget to add a reference to the assembly Microsoft.mshtml.dll distributed with WatiN):
Knowing this we now need to give this code a place in the WatiN architecture. With the introduction of multi browser support in WatiN 2.0, the architecture of the WatiN API has been changed to allow adding new implementations for different browsers without having to change the WatiN.Core code. To create a new Browser implementation we need to create concrete implementations for the INative* interfaces specific for the browser we are adding. Since we are basing our new browser implementation on the same mshtml dll that Internet Explorer uses, we can reuse a lot of the IE specific native classes already available in the WatiN.Core.Native.InternetExplorer namespace.
But since we don’t want to use WatiN.Core.IE and need to use WatiN.Core.Browser to tap into the WatiN architecture, we need to create our own browser class. Lets call it MsHtmlBrowser (inheriting the abstract class Browser). This forces us to implement 2 abstract methods (WaitForComplete and Close) and 1 abstract property (NativeBrowser). Lets focus on implementing the NativeBrowser property.
NativeBrowser returns a type implementing INativeBrowser. So lets create a class MsHtmlNativeBrowser which implements INativeBrowser. This requires several methods and properties to be implemented. Many of these we can’t provide an implementation for since we aren’t wrapping a real browser. Two of these we need to focus on NavigateTo(url) and the property NativeDocument.
As you might guess, we can add our code (to load a page in an HtmlDocumentClass instance) to the NavigateTo method. After initialization of the object we wrap it into an IEDocument which will be returned by the NativeDocument property. Following the implementation. All the other methods do throw a NotImplementedException.
Back to implementing MshHtmlBrowser.
Now that we have MsHtmlNativeBrowser, we can return an instance of this class in the NativeBrowser property of MsHtmlBrowser.
The implementation of the Close method is empty since we don’t have a real browser we need to close. You might consider disposing the instance of MsHtmlNativeBrowser here.
For the WaitForComplete method we can reuse functionality in the IEWaitForComplete class by passing in the IEDocument instance of the MsHtmlNativeBrowser.
This results in the following implementation:
Which concludes this example on creating a browserless Browser implementation.
Enjoy testing with WatiN!
Just a shameless repost of a mail Jeff Brown did send to the WatiN mailinglists. Interesting stuff, go check it out!
I just released Gallio / MbUnit v3.1 Update 1.
It's mainly a bug fix release but I also added some new samples
demonstrating one good way of using WatiN with MbUnit.
The sample introduces a new custom attribute called [Browser] with some
fancy behavior like:
* Capturing a screenshot if the test fails (or whenever you like).
* Embedding a video capture of the test run if the test fails (or whenever
you like).
* Running the same test repeatedly with different browsers.
The code is pretty easy to use so if you're already using MbUnit v3 and
WatiN then you should find it pretty easy to incorporate some of these
features from the samples into your own tests.
After installing Gallio v3.1 Update 1, look in %PROGRAMFILES%\Gallio\samples
for the WatiN samples and unzip them to a location of your choice. You'll
need Visual Studio 2008 SP1 to run them out of the box.
Here's one of the sample tests to give you an idea of how this looks:
/// <summary>
/// Runs the same test repeatedly with different browsers.
/// </summary>
[Test]
[Browser(BrowserType.IE)]
[Browser(BrowserType.FireFox)]
[Browser(BrowserType.Chrome)]
public void MultipleBrowsers()
{
GoogleSearchPage.GoTo(Browser);
Browser.Page<GoogleSearchPage>().Search("Fiddlesticks");
}
Full announcement and download links:
http://blog.bits-in-motion.com/2009/10/announcing-gallio-and-mbunit-v31-upda
te.html
You can also see a sample video capture from a previous release here:
http://www.youtube.com/watch?v=rN0CmutflFs
Enjoy,
Jeff.
This is a shameless plug for a FREE presentation by David Hussman about Agile Software Development. So if you are in the Netherlands on September the 16th sign up!
Following the invitation for this FREE event (or visit the LinkiT site for the dutch invitation)
On September 16 LinkiT projects provides a presentation on Agile Software Development. The presentation will be given by David Hussman. David Hussman coaches organizations all over the world to adopt and apply Agile principles, techniques and tools. From the recent past there is a close link between David and LinkiT projects, created by an intense collaboration.
For more information about David Hussman, see www.devjam.com.
The presentation consists of two parts. In the first part David talks about why Agile Software Development came to existence, how to make the transition from waterfall to Agile, what pitfalls there may arise, and how to stay agile. In the second part of the presentation David will zoom in on a number of techniques used in Agile Software Development.
Agile software development is currently 'hot'. The most popular methods are currently Scrum and XP, with Scrum being project management focused and XP focuses on the development techniques.
Date / Time: Wednesday, September 16 18:00-21:00
Location: The office of LinkiT, Rijnzathe 9, de Meern, Netherlands (here)
Attending the presentation is free of charge, but the number of seats is limited!
Audience: Developers, Project Managers, IT Managers, CIOs, Architects & User Managers
In my previous blog post I explained how you can use the new Page class in your code. Having this class available did spark some new ideas in the community. And again Jeff Brown offered some hours of sleep to make your page classes even more terse by introducing the FindByAttribute. Another new attribute is the DescriptionAttribute.
The FindByAttribute can be used on Fields and Properties and gives you a declarative style of expressing how an element should be found. In the following example the GoogleSearchPage is revamped and makes use of the new FindByAttribute.
Note that I only changed the GoogleSearchPage class and didn't have to change the test. And yes indeed, no actual c# code is needed and it almost reads like a real sentence. If only we could get ride of the syntax overhead like the [()] public:
FindBy Name q TextField SearchCriteria
When you create your first automated tests with WatiN you are happy with the results and how easy it is to create tests (at least that is what I keep hearing). Your happily copying and pasting code to find elements into new tests. While your test suite is growing rapidly, changes are made to the web pages and all of a sudden you are in a test code maintenance nightmare. You have created WET code (!= DRY). The solution: separate your test code in tests classes, page classes and control classes (more on controls in another post). So lets start mopping!
Richard Griffin, James Avery and Ayende Rahien all wrote about the problems they were having and the page model they developed. Bruce McLeod even posted the WatiN Jobsite Sample on CodePlex to show you his page model in action. Thanks to the work of Jeff Brown, WatiN 2.0 beta 1 now comes with its own page model. The basic idea of a page model is that each web page in the web site under test has a page class counterpart in the test suite. These page classes expose elements through properties and actions through methods. The result makes it much easier to create new tests and to maintain your test code when changes happen to your web site.In this post I’ll transform the Hello world example of web test automation, as shown on the WatiN homepage, into a test using such a page class.
First a new class needs to be created inheriting the WatiN.Core.Page class, lets call it GoogleSearchPage. This page class exposes properties for the searchcriteria field and the search button. After re-writing the “Hello world example” using the GoogleSearchPage class, the code looks like this (and of course you would put the GoogleSearchPage class in its own file/assembly in production code, but for this example I kept them together).
The Page<> method on the Browser class provides an easy way to instantiate page classes and it does inject the Browser Document into the page class. Because the GoogleSearchPage inherits the new WatiN.Core.Page class, it can access to Document property exposed by the Page class to find elements on the page.
Since the GoogleSearchPage has properties exposing the SearchCriteria textfield and the Search button, all logic to find these controls is held in one place and can be easily reused in other tests. Also notice how the test got much more readable compared to the example on the WatiN website.
Ok, so we have modeled the page with its elements, lets take it one step further. Most web pages offer users one or more actions they can perform on the page. Modeling these actions as methods on your page class would encapsulate even more logic into one place and thus making it easier to maintain when changes happen to the web page. So let me add the method SearchFor to the GoogleSearchPage. Also see how it improves the readability of the test, again.
At this point, when I would navigate to http://www.bing.com and use the GoogleSearchPage, nothing would alarm me that the current page can’t be automated with the GoogleSearchPage class. Instead an ElementNotFoundException would be throw when trying to find an input element with the name btnG (in the SearchCriteria property).
The new Page class offers you some ways to validate the current page before accessing elements on the page. The easiest way is to decorate a page class with the new PageAttribute. This attribute exposes a property UrlRegex which accepts a regular expression. This is used to match with the current browsers Url every time the Page.Document property is accessed. WatiN will check if the browser is still on the correct page and if not, throw a meaningful exception.
If the regular expressions are not your thing or you want to check against another aspect of your page (for instance the title), you can also override the Page.VerifyDocumentProperties method and implement your own check and not use the PageAttribute.
Wel that’s it about the new Page class in WatiN 2.0 beta 1. I hope it will help you to better structure your page model. Following our revamped Hello world example of web test automation.
I have been thinking for a while about creating a How To screen casts series about WatiN. Last week I sat down and experimented a bit with Jing by TechSmith (the creators of CamtasiaStudio).
With Jing it really is very easy to get started with recording and not falling into the trap of creating the visually perfect video with Camtasia. Which, at the end, never gets done. I also like the 5 minute constraint that Jing enforces. This really makes you to focus on the core of things you want to example or show. And last but not least, they offer a 2 GB free storage on screencast.com to host your videos.
For this How To trial episode I used this blog about adding your own elements to WatiN. Let me know what you think about it? Do you like the length, the amount of information, should I do more like these and which topics would you like to be explained?
Many questions on the watin-users mailinglist (and about WatiN in general) are about handling dialogs with WatiN. WatiN has build in support for handling many of Internet Explorers dailogs but it is hard to find out which DialogHandler is the right one for the job.
WatiN 2.0 beta 1 introduced the new DialogHandlerHelper class. DialogHandlerHelper can be used to investigate which DialogHandler can be used for a specific dialog. The following example shows you how to use the DialogHandlerHelper .
Lets walk through the example. First it creates an IE instance and navigates to a page. Then an instance of DialogHandlerHelper is created and registered with the DialogWatcher. A button is clicked which shows a dialog. The DialogHandlerHelper will now inspect the dialog and close it. Finally the CandidateDialogHandlers are written to the console window for you to inspect and create your final solution.
For this example that would be:
To make it even more simple, wouldn’t it be great if someone combined the following into a windows forms app:
Volunteers?
I was going over the WatiN questions on stackoverflow. One of the questions involved reusing an IE instance over multiple tests. Since Visual Studio’s test runner creates a new Thread for each TestMethod in a TestClass you get a nasty InvalidComObjectException with the additional information "COM object that has been separated from its underlying RCW can not be used.".
Following the problem example as posted on stackoverflow. When running these tests, the first test “testOne” passes but the second test “testTwo” will throw the InvalidComObjectException.
Does this mean we can’t reuse an IE instance across multiple tests? Nope.
We can still instantiate IE in the method decorated with the ClassInitialize attribute but in each test case we need to attach to the running instance using IE.AttachToIE(constraint). To find the Internet Explorer instance we created, we can use the window handle to find the instance. Somewhat like a “good-old-pointer”. Add a little bit logic to cache the found IE instance and return this as long as the CurrentThread hasn’t changed and the helper class could look something like this:
To make use of this helper class, we create an instance of IEStaticInstanceHelper and assign it to a static field (as we did before with the IE instance). Next we assign an IE instance to the IE property. Now we can use this Internet Explorer instance in our test cases without bothering about different Threads.
For clarity sake I wrapped the call to the ieStaticInstanceHelper.IE property in an instance property of the test class, called IE. And to make sure the IE instance gets closed after all tests have run I added a method decorated with the ClassCleanup attribute.
Off course you could create a base class which is used by all your test classes, but that's up to you.
You can download the code here.
Happy testing with WatiN and Visual Studio test runner!
I’m very happy to announce the release of WatiN 2.0 beta 1!
It has been a long ride from the first CTP release to this beta release. This has mainly to do with the beta having a completely different architecture from the previous CTP releases. With the CTP releases we used interface like ITextField etc. to provide support for multiple browsers. This resulted basically in creating a complete new set of about 50 classes for each additional browser we wanted to support. With this release we have managed to reduce this amount to 6 classes for each additional browser.
Another big change is made to the test suite. All the tests that came with WatiN 1.3 and were run against Internet Explorer, making sure every feature worked with IE6 and IE7, are now run against FireFox 2 and 3 and IE8 as well. This ensures that all features have the same behavior across all these browsers.
We are not there yet, that’s why it is still a beta release. We will continue working on WatiN 2.0 to fix the list of known issues and to incorporate community feedback. We intend to do a release at the end of every month, working towards a final release in June or July.
In the coming days I will blog some more about the new features. For now you can read the release notes at http://watin.sourceforge.net/releasenotes-2-0-10-x.html and download the release here.
Happy testing with WatiN!
Update 3/31/2009: You can download the example code for this blog post here.
Still working on the beta release of WatiN 2.0 (will ship in the next few days), but I felt the need to blog about a new feature in the 2.0 beta. In previous posts I showed you how you could extend WatiN with your own controls:
In the upcoming beta WatiN will offer you these new features:
Which make the previous posts obsolete.
WatiN doesn’t provide support for all html elements defined by the W3C standards. For instance there is no out-of-the-box support for li tagged elements. But starting with WatiN 2.0 beta 1 you can “add” support for linked lists yourself.
First lets show you how you could make use of your own ListItem element.
ListItem list = browser.ElementOfType<ListItem >(Find.ById(“theElementId”));
(And yes, this syntax also works with the out-of-the-box elements like TextField etc..)
Now we know how we could use a none native ListItem element in our (test) code, lets create this ListItem class.
ElementFactory.RegisterElementType(typeof(ListItem ));
That’s it, you’ve added a new (almost native) element to WatiN. You could make it look even more native by extending the IElementContainer interface with some extension methods which do wrap the calls to ElementOfType<ListItem >(…) and make it look like:
ListItem list = browser.ListItem (Find.ById(“theElementId”));
I’ll tell you about that one in my next post… back to releasing the beta :-)
I'm happy to announce the third CTP release of WatiN 2.0, offering support for both Internet Explorer and FireFox.
Enjoy testing with WatiN!
I'm happy to announce the second CTP release of WatiN 2.0, offering support for both Internet Explorer and FireFox.
Thanks to Edward Wilde for making it work with FF 3.x
Enjoy testing with WatiN!
In my last post I talked a bit about what was going on with the project. Following is an update on that post.
Edward Wilde has made some changes to the current CTP code to support FireFox 3.x as well. This will be released within one week. Edward Thanks!
Development for the first beta is still in progress. The FireFox specific classes are added and progress is great! Still on track for a first beta in Q1. Just to give you a feel off what is already working, the following test fixtures in the WatiN.Core.UnitTests assembly do run against IE (7) and FireFox (3.1):
Another very interesting initiative regarding the 2.0 version is taken by Jon Dick. He started last week writing a browser implementation to run tests with HtmlUnit. This is an in memory, no GUI browser written in Java. Combined with IKVM he already has the google test example running. Since this browser skips rendering it makes the tests run faster which is always a good thing.
I also wondered of a little bit last week and took a look at automating Chrome (the new browser by Google). One option is to use a telnet session to the browser, much like we currently do for the automation of FireFox (using the jssh plug-in). So hopefully after finishing FireFox support, Chrome support will be there very quickly.
Although I have created the branch and already merged a lot of the fixes from the trunk, I still need to add the changes I made to the DialogHandlers which do type text in a dialog (like the prompt dialog, file upload dialog and file download dialog). I think it is worth waiting cause this will (finally) fix the hanging of WatiN test in a VPC or closed/minimized remote desktop session. Hope to get this done soon.
Although I don't do any development on WatiN test recorder project (All credits go to Daaron Dwyer!) I know he is busy working on a 2.0 release. So if you have feature request, this is the time to contact him or spam the trackers on sourceforge :-)