WebAii Silverlight Extension CTP2 Released!

We are happy to announce the release of CTP2. You can download it from our downloads pages http://community.artoftest.com/files/ .

This CTP is tested against Microsoft's official Silverlight 2 Release. CTP2 fixes all issues reported in CTP1. The dowload entry description contains all the major fixes. I will list them again in this post:

1. Connecting to Silverlight Apps. If you were using CTP1, you might have noticed that our extension stopped being able to connect to Silverlight apps once Microsoft released RC0. In RC0 Microsoft disabled one feature that we were relying on to plug into the app (Security reasons). Instead of trying to hack around this, we simple leverged our built-in http proxy (a new WebAii 2.0 feature that will be fully exposed using an OM but currently marked internal in this release) to connect to the app. This made our execution much cleaner and faster. No more reloading of the app or anything. It should be seamless. The only limitation we have right now is HTTPS.

>> NOTE: In CTP2 there is a new Setting.EnableSilverlight flag that needs to be set to enable WebAii to connect to Silverlight applications. By default this setting is not on. Setting this flag will activate the built-in proxy that we use to detect Silverlight applications.

2. Silverlight UI Controls. All our Silverlight controls that we ship in the box are now extensible. We removed the sealing of these classes. So anyone that wanted to extend them to build their own classes can do so.

3. Silverlight Test Template. As part of the installation, you now have a Silverlight test template that you can use to get you started. The template has one sample test that automates a simple silverlight app.

4. Bug Fixes/Additional Features worth noting:

1. Finding child elements bug: http://community.artoftest.com/forums/p/453/1748.aspx#1748
2. Application duplication: http://community.artoftest.com/forums/p/450/1643.aspx#1643
3. Ability to move the mouse in a certain path: http://community.artoftest.com/forums/p/442/1598.aspx#1598
   

This is going to be the last standalone CTP2 for silverlight and the silverlight automation functionality you see in thie extension will be rolled into WebAii 2.0 next many other cool new features. Keep an eye on our blogs in the next few weeks where we will preview the roadmap for WebAii 2.0.

Have fun automating.....

Automated Testing of Silverlight Applications – PART II – WebAii’s Support Preview

It's been over a year now since we outlined our vision for supporting Silverlight test automation. We have looked into Silverlight automation from every angle and considered all approaches including UIAutomation. Our automation support for Silverlight doesn't really rely on UIAutomation but at the same time doesn't exclude it 100%. We will probably dedicate a full blog post about this topic and discuss how we are integrating UIAutomation and our reasoning for not relying on it 100%. But for now, let's just dig into our first preview release that will include Silverlight Test Automation support. Officially we are calling this release : WebAii's Silverlight Extension (CTP1) and the release will be available early next week. We are hoping this will be the first extension in a series of WebAii extensions that customers can pick and choose from that cater to specialized technology areas. (i.e. extensions for WebServices, WCF, Data …etc).

Getting started with Silverlight Automation in WebAii

To get started, let's first use a simple application and demo some basic automation scenarios like button click and set text. We will then expand into more advanced topics and scenarios.

Let's take the following simple Silverlight application that contains a button and a text box. When you click the button, it simply displays hello in a textblock on the canvas. The application looks like this:

To automate the application above to set the text, click the button and then verify the hello text in WebAii, we can simply write the following code using WebAii's Silverlight Extension (which currently resides under ArtOfTest.WebAii.Silverlight). Eventually we will be moving this into its own dll/extension:

Let's take a closer look at the code above line by line:

Line 319-323

This is basic WebAii code that launches the browser and navigates to a specific page.

Line 326

As soon as you include the Silverlight extension namespace in your test, (ArtOfTest.WebAii.Silverlight), the 'SilverlightApps()' extension method is added to the ActiveBrowser. The extension method offers you a list of all Silverlight applications found on that page. The extension method returns a list that has two accessors. An index accessor that takes an int (as shown above) and an string accessor that takes a hostid [The id of the html element that contains the <object> tag for the plug-in]. You can pick and choose what works for you. In this sample, given that we only have one Silverlight plugin on the page, we simply accessed the first and only one.

Line 329

As soon as you have an instance of a SilverlightApp, you now have full access to the application including the entire VisualTree. The app offers a short-cut method 'FindName', that can be used to search the application using an element name. In the above sample, given that the TextBox has a name associated with it, we can use FindName to locate it. The SilverlightApp object offers two versions of 'FindName': The first is a generic method that can return a strongly-typed object of the element (As shown above , i.e. a Button, a TextBox, a Grid…etc). The second is simpler and returns the base FrameworkElement object. We will discuss the strongly-typed object model offered in WebAii Silverlight Extension later in this post.

To go back to the line above, we are simply accessing the TextBox that has a name 'myName' and then setting its Text property to "ArtOfTest". Note that given we are accessing a property on the element, this is analogous to SetText on a DOM element in web automation. You are not really typing the text in the textbox but rather setting the Text property inside the application to that text. Our extension enables you to access and set properties directly against any FrameworkElement. If we wanted to simulate real typing of the text we would have written code like this:

app.FindName<TextBox>("myName").User.TypeText("ArtOfTest", 50);

Line 332

Same as above in terms of accessing the button. The difference here is that we are using the 'User' object to click the button. The User object is presented off all elements that inherit from FrameworkElement and offers real user interactions with Silverlight elements. So a Click off 'User' will actually move the mouse over that button an click it. That is exactly what this line does.

Line 335

Now that the button is clicked, we need to verify that the message is correct. The difference here is that we can't really use FindName to locate the TextBlock because the TextBlock doesn't really have a name. The SilverlightApp object offers extensive search support within the VisualTree beyond FindName() by utilizing similar approach to the Find object off the ActiveBrowser (that is used for HTML DOM searches) but adapted to specific XAML search scenarios.

In our code above, we are searching for a TextBlock (All Find.xxText() routines return TextBlocks) that partially contains 'Hello', hence 'p:Hello' (Similar to Find.ByContent in HTML search). Once we find the TextBlock, we then verify that the Text of that label is actually 'Hello ArtOfTest' using the Assert.IsTrue.

Now that we understand this sample, let's dig into some of the key objects available in WebAii's Silverlight Extension.

The SilverlightApp object

The SilverlightApp object is the main object you interact with when automating a silverlight plugin and is the entry point into the silverlight plugin. Below are some of the key properties/methods offered by the SilverlightApp object:

SilverlightApp.Bounds	Returns a Rectangle object that is the actual screen coordinates of this Silverlight-plugin.
SilverlightApp.Content	Exposes the properties found on plugin.content. (i.e. ActualHeight/ActualWidth/FullScreen)   Note: All properties are currently read-only.
SilverlightApp.Settings	Exposes the properties found on plugin.settings. (i.e. Background/EnableHtmlAccess/EnableFramerateCounter…etc)   Note: All properties are currently read-only.
SilverlightApp.VisualTree	The entire VisualTree of this application. The VisualTree can be navigated up and down and the root element can be accessed using VisualTree.Root. The elements accessed from the VisualTree are FrameworkElement objects.
SilverlightApp.Plugin	Returns an HtmlControl object that represents the actual HTML object tag of the plugin.
SilverlightApp.Host	Returns an HtmlControl object that represents the actual html tag that the plugin object tag is contained in. Typically this is a Div tag if you are using Visual Studio's Silverlight designer.
SilverlightApp.Find	Exposes a Find object used to search the VisualTree for FrameworkElements. This property is a shortcut to the VisualTree.Find object.
SilverlightApp.FindName/FindName<T>	A shortcut to the Find.ByName & Find.ByName<> methods used to find an element using its xaml set name.

 

The VisualTree

The VisualTree object exposed by the SilverlightApp is a hierarchal representation of the actual VisualTree of the Silverlight application at a specific point in time. If your Silverlight application changes, you can always refresh this tree by calling VisualTree.Refresh(). The VisualTree also exposes the VisualTree.Root property which is a FrameworkElement that represents the root element of the VisualTree of the app.

Note: To help eliminate any synchronization issues between the VisualTree available to the test client and the actual app running in the browser, every time the Find object attempts to find an element in the tree, it will always refresh before starting the search to ensure that the tree is up-to-date with the application.

Locating elements

For complex applications, locating elements is probably going to be one of the more time consuming areas where testers need to spend time understanding how to reliably find an element. Real Silverlight applications that we studied that rely heavily on control templates and databinding produce quite complex visual trees that contain elements that are not easily searchable by FindName() given the different namescopes created and the duplication of names within these templates. For example, check out the following application built by Telerik (http://www.telerik.com/demos/silverlight ) , the VisualTree for this application is quite complex.

The SilverlightApp.Find (Same object as VisualTree.Find) offers a rich set of search methods that enable you to not only find elements using their names but also by their text or type. Combined with type filtering, LINQ, FrameworkElement navigation (discussed below) and the Find.Allxxx routines, you get a pretty rich set of routines that enables you to find any framework element in the tree. That being said, this area is probably the area where we would really like lots of feedback in terms of additional search routines customers would like to see and scenarios that we need to support better or make easier. Here is a quick listing of the search routines available in this release:

Find.AllByName()/Find.AllByName<T>	Find all elements that have a specific name. Allows filtering on a specific control type.
Find.AllByText()	Find all TextBlocks that contain a specific text. Use p:text to search for partial text
Find.AllByType()/Find.AllByType<T>	Find all elements of certain type. i.e Button, Grid..etc. Filtering on type is inherit here.
Find.ByName()/Find.ByName<T>	Same as FindName(). Search using a specific name.
Find.ByText()	Returns the first TextBlock that matches the text provided.

 

Note: All the generic find methods also have a none generic companion for cases where you are working with control types that are not available in the ArtOfTest.WebAii.Silverlight.UI namespace.

Find.Strategy

Unlike the ActiveBrowser.Find, the SilverlightApp.Find allows you to configure the FindStrategy that you wish to use when locating elements. By default we use the AlwaysWaitForElementsVisible which provides the most reliable approach to locating elements and eliminates any timing issues between the application and the test. So by default when we locate an element we will try to find it, if we don't find it, we keep trying until the element is available up to Find.WaitOnElementsTimeout. You can change this strategy at any point in time. Your options are:

FrameworkElement object

The FrameworkElement available in WebAii's Silverlight Extension is analogous to the FrameworkElement in Silverlight and is the base object that all visual elements and controls inherit from in the ArtOfTest.WebAii.Silverlight.UI namespace (discussed later below). For customers interested in our extensibility model, WebAii's Silverlight Extension does not expose a UIElement and therefore, our FrameworkElement can be viewed as the combination of Silverlight's UIElement + FrameworkElement.

The FrameworkElement and all objects that inherit from it get the following infrastructure methods and services:

1. VisualTree navigation: All FrameworkElements enable you to navigate the visual tree up or down. The object exposes methods and properties like Parent, Children, NextSibling, PreviousSibling, AnySibling<T>. The navigation also supports control sensitive navigation. For example, if you would like to find the parent 'Grid' that a certain text is contained in you do the following:
   

   
    

   Grid containerGrid = app.Find.ByText("SomeText").Parent<Grid>();
   

   OR
   

   If you are working with a custom control that doesn't have a strongly-typed object under ArtOfTest.WebAii.Silverlight.UI, the navigation methods all offer a non-generic version that can be used to search for a certain type. For example, let's say you are trying to find the custom control "Bar" that contains some text, then you can do the following:
   

   FrameworkElement barElement = app.Find.ByText("SomeText").Parent("Bar");
   

   Parent, NextSibling, PreviousSibling & AnySibling all offer a non-generic versions in addition to the generic one.
   

2. User Interaction object:
   The FrameworkElement object exposes a user interaction object. The object is exposed as a property named 'User'. User then exposes all the real automation methods like moving the mouse to click an element, type a text, mouseenter, mouseleave…etc. Here is a listing of all the methods exposed in this preview release
   
   

   

   
   

   Note: One of the reasons why we moved these methods into their own object under 'User.xxx' is to help users differentiate between automation that is done by setting/getting properties vs real automation that does use the mouse or keyboard to invoke an action. That is one feedback we got on our design for the HtmlControls suite where customers didn't know which method actually used the real mouse vs direct DOM interaction.
   

   
    

3. Element coordinates: All FrameworkElements offer the ability to get both the relative coordinates of the element within the silverlight application and the actual coordinates in screen coordinates. The two methods are GetRectangle()
   and GetScreenRectangle().
   

   
    

   Note: Given that WPF/Silverlight applications allow for rich transforms for visual elements (i.e rotate, zoom….etc) and some elements like ellipses don't really conform to a rectangle per-say, our coordinate calculations will always return the largest rectangle that contains the actual element with its center right at the center of the element. For example, a GetRectangle on an ellipse will return this:
   

   
   

   

   
   

   [Note the highlighting above is using the FrameworkElement.Highlight() method]
   

   
    

4. Scoped search within an element visual children.
   Every single FrameworkElement also has a Find object associated with it that searches only this element's child visual elements. This object will prove very useful when getting into more complex application automation scenarios.
   

   
    

   Example: Find the first StackPanel in the application that contains a specific text:
   

   StackPanel panel = app.Find.AllByType<StackPanel>().Where(sp => sp.Find.AllByText("SomeText").Count > 0).First();
   

5. Visual Synchronization:
   Silverlight applications and the richness they offer to developers in terms of scenario building, accentuate
   the need for rich synchronization support within an automated testing framework. Any testing framework that wants to be considered as a serious and dependable test automation solution within the enterprise for Silverlight needs to offer rich support for synchronization between the application under test and the test being executed. For that reason, all FrameworkElement objects also expose a Wait object that is used to syncronize that element against specific check points. Currently our support is limited to Visible, VisibleNot. Future support is planned for event waiting, animation synchronization and much more. Again feedback on this feature from customers would be of great help.
   

   
    

6. Xml Representation:
   Every FrameworkElement has a ToXml() method on it that returns the VisualTree of that element as an XML formatted string. This is very useful when trying to understand the visual tree at a certain state. [Hint: You can get the entire visual tree of an app by calling app.VisualTree.Root.ToXml()]
   

   
    

ArtOfTest.WebAii.Silverlight.UI namespace

The UI namespace includes all the strongly-typed controls like Button, TextBox…etc including their properties/methods and enums. The namespace also includes types used by these properties like Brush, SolidBrush…etc. In this preview we are only claiming support for simple primitive property setting/getting and enums. Later on, we will be supporting the ability to retrieve and set complex types like setting a SolidBrush on a Background or retrieving a specific Transform properties from an object. Although setting/getting these types of properties might seem outside the scope of test automation but these properties are going to be much needed to help with test case synchronization with that application and will make it much easier to craft verification points within an automated test. [i.e. Enabling scenarios where a test will need to wait until a specific storyboard has finished a specific animation or waiting/verifying that a specific trigger has been triggered or a certain DependencyProperty has changed…etc.]

Current limitations with this release:

1. On Vista, if you are automating an external website, then make sure to add the url to your Trusted WebSites list in IE.
   
2. Our automation targets Silverlight 2.0 (Beta2) and doesn't support any previous versions.
   
3. The automation supports only .XAP deployment method.
   
4. EnableHtmlAccess needs to be set to 'True' on your application.
   
5. ArtOfTest.WebAii.Silverlight.UI does not contain controls in the System.Windows.Controls.Extended namespace. This will be available in future releases.
   
6. There are known issues with Silverlight applications that attempt to perform webservice calls within the application. This issue will be resolved in future versions.
   
7. This release does not support side-by-side installation with any previous versions of WebAii or Design Canvas.
   
8. The application needs to be running off http:// not C:\...
   
9. VS Debugging. Currently the experience of inspecting objects while broken in the debugger is a bit rough. You get lots of timeouts. This will be resolve in future versions.
   

What's next?

This is our first CTP preview for Silverlight automation. One of the goals of this release is to gather feedback from customers on our design and get specific feature requests that customers want to see implemented. That being said, we still have a set of features that will be implemented in future previews and beta releases of this extension to WebAii, specifically:

1. More synchronization support within the Wait object for animation and events.
   
2. Ability to trigger specific events on an element.
   
3. Extended support for setting/getting complex types.
   
4. Rich support for interacting with custom Scriptable objects.
   
5. Debugging and Tracing support.
   

That's pretty much it for now. We are very excited about this release and look forward to your feedback. Feel free to send feedback directly to us: http://www.artoftest.com/contact.aspx

You can download CTP1 build from here.

Enjoy,

ArtOfTest Team

Browser-agnostic color verification using WebAii & Automation Design Canvas

Color style verification in WebAii and Automation Design Canvas is one of those nice-to-have features that saves testers some cycles especially when trying to make an automated test run cross browser (specifically in IE and Firefox). If the application you are testing uses style sheets - which most of today's rich web applications do – there is a good chance you might have to verify a style on a specific tag or that a specific tag has changed color based on its cascaded style sheet. WebAii and Automation Design Canvas offer specific functionality to help address the color formatting for computed styles.

Let's first take at look at why computed styles for color verification causes problems for testers:

The issue is related to how IE and Firefox return colors when it comes to computed styles:

In IE, computed styles accessed using (element.currentStyle) return color (i.e. backgroundColor, foreColor) using the following format : #xxyyzz

FireFox on the other hand always returns the color in the following format: rgb(x,y,x)

Typically , when writing automated tests for such a scenario (that you wish to run on both IE and Firefox), you end-up having to fork your code based on each browser type and do the validation using the specified format.

Well not anymore…., let's take a look at what WebAii 1.1 offers in terms of support in this scenario:

WebAii 1.1 Framework

There are several built-in features in WebAii framework that address this scenario:

1. HtmlStyle object:
   

   If you notice, our HtmlControl.GetComputedStyle() returns an HtmlStyle object, not a string value. The GetComputedStyle() function retrieves the style from the browser DOM and places it in the HtmlStyle object for further processing. If you wish to get the value immediately, you always call the HtmlControl.GetComputedStyleValue() which gets the actual style value as a string.
   

   The HtmlStyle object offers the following facilities to make style validation simple and more straigh-forward for colors:
   

• HtmlStyle.IsColor(): This call checks to see if the style returned is a color or not. If for any reason you have code that generically processes styles, you can use this to distinguish between color styles and other styles
  
• HtmlStyle.ToColor(): This method is very powerful and is where we abstract out the formatting between IE and Firefox. This method simple parses the value out for you and returns a System.Drawing.Color object that you can then use to validate against another System.Drawing.Color you might want to check against.
  

For example:

The following line of code can be used to validate that the background computed style color for a div is red. This line of code works for both IE and Firefox:

Assert.AreEqual<Color>(Color.Red, myDiv.GetComputedStyle("backgroundColor").ToColor());

1. AssertStyle() extensions.
   

   In WebAii 1.1, we introduced verification extensions to help facilitate HTML specific validation. The AssertStyle() class takes advantage of the above functionality to abstract out the browser formatting specifics and make color verification completely seamless.
    

   For example:
    

   The following validation will assert that the backgroundColor style on the Div tag is red regardless of the browser used.
    

   myDiv.AssertStyle().ColorAndBackground(HtmlStyleColorAndBackground.BackgroundColor, "Red");
   

Automation Design Canvas 1.0

In Automation Design Canvas 1.0 (ADC), we consume the above functionality inside the style verification sentences and we make it completely straight forward to craft and execute color verification. In ADC, we internally persist colors in #XXYYXX format and always covert (named/rgb/#xxyyzz) colors to the #XXYYZZ format. Using that format comparisons are done. Here is how a color style verification looks like in ADC 1.0:

For example, if you invoke verification to validate the forecolor of the following text on msn.com home page:

The verification sentence builder will automatically resolve the color to its #XXYYZZ format as shown below.

Definietly a craft and forget color validation. J.

Automation Design Canvas 1.0 : Test Failure Resolution

One of the key features that we are proud of in Automation Design Canvas 1.0, is the designer's ability to help testers maintain and fix their automated tests. Automated testing is not only about how fast you can record a test but also how fast you can analyze and resolve a test failure. Some of the key features included in Automation Design Canvas 1.0 are:

1. Visual State Capturing: As you record each step, the designer captures the browser state at that point in time with the target element highlighted on the surface. Each visual step is then added to the story board so that you can visually go back to it. Each visual step is also tied to the actual step, so as you re-order your steps and move them around or delete them, your visual story board of your test is always up to date with your latest changes. The goal of this feature is to help you understand where elements were at the time of recording and what the entire page looks like at that moment in time. In some cases, these visual captures can help you pin-point a failure by simply looking at the captured images.
   
2. DOM State Capturing: One thing we realized too is that capturing the visual state is not enough. In many cases, the failures are due to issues like ID changes or attribute value changes on HTML elements and such failures rarely exhibit any visual change. You actually need the DOM state at that moment in time to help you understand what changed in that DOM.
   
3. DOM Tree Diff View: When loading a failure in the Automation Design Canvas, the DOM Tree tool window enables a "DOM Diff" view that you can be use to help understand the differences between Recorded & Executed DOMs. Such a side-by-side view is an enormous help in allowing you to inspect property or DOM structure changes between when the step was recorded vs its execution.
   
4. DOM Element Index View: Each element in the DOM Tree is prefixed with its TagIndex. Combined with the Diff View discussed about, this gives you a fast path to detected and match two DOM nodes between the recorded and executed DOM trees.
   
5. Live Validation: For both Element Identification & Verification Rules. As you are investigating your failures, you can easily edit the failing rule for identification or verification and validate it against the executed DOM.
   

To help us demonstrate these features, lets take a simple example of a common failure for web automation: Element Id Changes. Let's start by taking this HTML Page:

As you can see, the input button has a "btn1" id associated with it. Let's load this page in Automation Design Canvas 1.0 and record the button click. The Automation Design Canvas will determine that the best method to identify this element on the page is using its id (btn1) given that the ID is currenly set on the page and is unique. For more information about how Automation Design Canvas builds identifications for elements including how to customize them, check out our help topic here.

Here is what the FindParam editor looks like:

If you run the test, obviously everything should pass…

Let's now say a few weeks later, the developer of this application decides to change the button's ID from "Btn1" to "Btn2". Let's go ahead and make that change in the page and run the test again:

Now that we are at this stage, let's see how Automation Design Canvas, can help us resolve this issue. To debug a failure in Automation Design Canvas, we will simply double click on the red x right next to the failing step. In design canvas, you get debug capability at the step level. When clicking on the red x, the Automation Design Canvas will open up the Debug UI for you. Let's take a close look at what that UI looks like and all its pieces:

If you open up the DOM Explorer at this point, you will notice that it also has a drop-down similar to the one listed above in the "Actions" section:

The first thing that comes to mind when debugging such a failure is what was the state of the DOM when I recorded my test.

Why can't my test find the "btn1" id. [As a tester, you might not be aware that this ID has changed]. Let's switch the Target DOM to "Recorded" and then click on the "Validate" button to see if I can still find the element in the DOM when I recorded it.

As you can see, the designer was able to find this element against the DOM that was captured at the time of recording. If you actually pull up the DOM Explorer and switch it to "Recorded", you will see that element highlighted in the tree:

We now atleast know that the FindParam used to identify this element is correct and that the failure must be due to a change in the page, not a problem in how we are identifying it. The next question to answer then, what changed and what is the new value for that change. To help identify that, let's switch the "View" of the "Recorded" dom to "TagName" so that we get a flat list of each tag with its index that looks like this:

Next we are going to compare this element with the actual "Execution" dom that the test failed again. To do so, let's simply switch the "Displayed DOM" to (both). And switch also the "Execution" "View" to "TagName". The DOM Explorer now displays both recorded and executed DOM side by side:

Now that we have both DOMs side by side, we can easily navigate the Execution DOM to the INPUT tag with index "1".

Ah!

Now we see that this element's id is btn2 not btn1. At this point there are two ways to proceed:

1. This is a bug in the product and should be reported.
   
2. This is an acceptable change and we simply need to update our automated test.
   

To update our automated test, simply go to the editor UI shown above and change the btn1 to btn2. Once you make that change, you might want to validate it against the execution DOM. Simply select "Execution" in the Target DOM drop down in the editor and click on the "Validate" button. The element should validate correctly and you are good to go at this point.

Click OK on the debug UI and you should be able to run the test again and it should pass.

Note: As soon as you click OK, the old recorded DOM is discarded for the Execution DOM since this is the DOM that the element has validated successfully against.

Powerful DOM Search & Validation using WebAii 1.1 & LINQ

One of the most powerful new (and probably least discovered) features of WebAii 1.1, is its expanded search support using LINQ. LINQ is Microsoft's latest technology introduced in .NET 3.5 that offers a highly rich and integrated query language inside .NET languages like C# or VB.NET.

It was relatively easy for us to realize how we can leverage the power of LINQ in WebAii. LINQ's most common use is to enable a rich syntax to query structured information and we thought it would serve a great purpose in also querying the DOM. Given that WebAii offers a 100% managed HTML DOM to the testcase, users can harness the full power of LINQ with their DOM Searches.

We first started by adding support to do LINQ queries on the Element object. So we introduced the Find.AllElements() that allows you to query the entire DOM tree using a LINQ expression.

For example:

Such powerful searchs makes it a lot easier and concise to do rich searches. Although this was a great enhancement to our search routine, we felt there is still more to be done. Most users are actually interested in querying a certain type of Html elements and not all of them. For example, if they want to query all tables, they will need to add another clause in the Where() clause that says element.tag == "table". In addition that, we realized that some of these searches might also want to leverage the strongly-typed HtmlControls suite that we have in WebAii. The HtmlControls suite offers a lot of rich context specific information regarding a specific Html tag. (i.e. Table's row count or even cell count). So if you are, for example, trying to use the Find.AllELements() to validate that all tables on a page have alteast 5 columns, you might have to write some pretty complex 'where' clause that defeats the purpose of making search easier using LINQ.

With that in mind, we decided that we definietly need to enable html filtering as part of our search API. We also thought that it would be great if we can make such filter based on a strongly typed HtmlControl type. For that purpose, we introduced the Find.AllControls<T>() function. This function is very powerful. I will use the rest of this blog post to go over some samples that use it.

Let's start with something simple. Let's say you simply want to get all the Images on a certain web page. With this API, you can simply do:

As you can see the Find.AllControls<T> already has all the information you need to get you the right set of images on the page. You can then loop through those images to do any validation or actions on them.

Let's take another example that leverages the rich API on our HtmlControl. Let's say you want to validate that all images on the www.gettyimages.com home page are actually loaded properly. In WebAii 1.1, we introduced the HtmlImage.IsLoaded() function that queries the DOM to validate that the image has actually loaded in the browser and is not a broken image. You can perform this validation in one line of code like this:

Very Nice, eh? Let's have some more fun with this API. Given that we are in elections season, let's say we want to go to Google's Elections News website and highlight all links that contain "Obama" with blue and "McCain" with Red. [Sounds like a CNN application to see who is getting more press J]. Here is the code that does this for us using WebAii 1.1:

If you have WebAii running, place the above code in a TestMethod and run it, looks pretty cool.

Ok, last, let's take a bit more complex validation scenario. Let's say we have a testcase that wants to validate that an ASP.NET DataGrid when put in edit mode, changes all the cells in Column 1 from labels to actual TextBox. How can we validate that?

We basically need to validate that:

1. All column 1 cells have one TextBox.
   
2. All column1 cells have only that textbox in that cell.
   

Here is the code using LINQ and Find.AllControls<> that does this for us:

That's it for now. We would love to hear your feedback about this feature or any other features in WebAii. We are in the process of revamping our online documentation to be more up to date with the WebAii 1.1 release. We are also starting an new effort to start blogging more about WebAii features and our Automation Design Canvas!!

Enjoy

Automation Design Canvas 1.0 Released!

Greetings!

ArtOfTest, Inc. is happy to announce the release of Automation Design Canvas 1.0! Automation Design Canvas is the test automation answer to today's rich web experiences and Ajax applications. It is available as a plug-in right inside Visual Studio Professional or Team Suite.

Since the release of RC0 we have focused solely on the quality and stability of the product to offer you a solid V1.0! We think we have an award winning product with lots of innovations.

Watch Quick Demo

Automation Design Canvas enables you to:

Build test automation in minutes vs hours

Shave weeks off your release schedules. No code to write or script to craft! Automation Design Canvas is built from the ground up to support rich Web 2.0 applications. It utilizes an advanced designer surface that makes test automation as easy as point and click, allowing for seamless crafting of verifications and syncrhonization for AJAX Pages.

Simple but powerful

A quick start guide is all you need to get started building test automation like a pro. The designer is highly customizable to allow advanced users to alter how recording is done. Recorded scripts are also extendible using an optional code behind model that allows developers to fully customize recorded tests whenever needed using WebAii Framework's rich .NET API. Using C# or VB.NET!

Built with maintenance in mind

Test automation needs to be constantly updated as the product being tested or the test environment changes. We have built-in features that give you the ability to rapidly resolve test failures and easily update your tests as well as track product changes through out the life time of the script using a DOM state archiving feature that can offer you DOM diffs.

Visual Studio Team System Integration

Design Canvas™ 1.0 is fully integrated in Visual Studio 2008 Professional & Team Suite. We add one additional test type to what Visual Studio offers. It integrates fully into the life cycle management of tests that VS offers including test case management, test execution, source control, remote execution and reporting using team foundation server. Futhermore, Design Canvas enables you to convert recorded scripts to VS Stress/Load tests.

Download Trial

Full features listing: http://www.artoftest.com/webaiidcproduct.aspx

How-To Videos: http://www.artoftest.com/webaiidcproduct.aspx?QS

WebAii 1.1 Released!

In conjunction with this release, WebAii 1.1 has also been released. Our next version of WebAii will be our 2.0 community preview which will include our Silverlight support that we have been working hard on.

ArtOfTest Inc.

Automation Design Canvas 1.0 (RC0) Released!

We are happy to unveil our RC0 of design canvas. RC0 represents the full feature set that we are planning for V1.0 release. RC0 also incorporates tons of feedback from our customers that have downloaded and used our beta. From this point on, we will only be taking bug fixes or major/adoption blocker features. We believe we have a very compelling and complete solution for dynamic web automation in this release. If you downloaded our beta we encourage you to upgrade to RC0. RC0 contains tons of bug fixes and additional features here are some of the major ones:

1. Dialogs Support: This includes both Html Pop-ups and Win32 Dialogs like alerts, logons or Download dialogs (For both IE/Firefox). We also included a "Generic" dialog handler for custom Win32 dialogs that enable you to define your own dialog titles, content search and how you want it handled.


2. Visual Studio Integration:
1. MSTest Execution: Execution using MSTest is now supported.
2. Create TestLists: We had a bug in that space. Now you can create TestLists, save them and execute them.
3. Data:
1. VS Data Sources: You can now drive your test using one of Visual Studio's supported data source like CSV files, XML Files and any DataBase. Select the test in "Test View", and click on "Data Connection String" in the properties window.
2. Data Range Constraints: Once your data is bound to a data source (Regardless if it is the built in data grid or a VS external source), you can define an iteration range to execute against. (i.e. 1:4, runs iteration 1 through 4)
3. Per Iteration Test Results: The Test Explorer now allows you to view test results on a per iteration. Pick an iteration from the drop down and the Test Explorer will be populated with the results for that specific iteration.
4. XML Based Elements Storage: In Beta our elements storage (i.e Elements.WebAiiElements file) was binary based. Now it is XML based and human readable.
5. Editing Elements in the Element's Explorer: In Beta that was restricted. Now you can easily update the names of Pages/Frames/TestRegions or specific elements with a Friendly Name that can be used to easily identify the element. These names will be used for code generation when you choose to convert tests to code.
6. Enhanced Element Search Alogrithm: We now use a more robust element search mechanism that tries to identify elements using single attributes then attribute combinations (included text content) before defaulting to tag index. Our testing showed how our algorithm produces highly reliable test automation. The algorithm is completely customizable using the UserSettings->Element Identification tab.
7. Page Url Configuration: The Page's Urls captured can now be configured/changed to customize how these pages are identified. For example, you can change a page to be identified by its Title vs its full url. Or maybe you want the page to be identified using the Base Url only or the Relative path + the query string. All of that is easily customizable per page.
8. SetText:
1. Automatic Password Detection: Automatically detects passwords and masks them.
2. SimulateRealTyping: You can optionally turn that on for that step and the text will be typed one letter at a time using a settable speed. This is great for automating scenarios like auto-complete text boxes.
9. WaitOnElements: All steps now have the option to wait on their elements to exist before executing the test. This is turned on by default. With this feature many of your dynamic applications no longer need an explicit Wait for Exists. You can optionally turn that feature off on a per step basis if needed. Each step also has a WaitOnElementsTimout that can be set.
10. Annotation Step Type: You can now add custom annotation messages within your steps with a configurable display time.
11. Capture Step Type: Add browser captures or desktop captures as part of your test to visually capture browser or desktop states during your test execution.
12. Simulate Real Click: You can now optionally use DOM Click (Default) or SimulateRealClick which will move the mouse to that element and click it like a real user.
13. Browser Constraints: You can now configure specific steps to run only on specific browser types. (i.e. Run this step only on Firefox or IE or both)
14. Pause: You can optionally pause your execution right before or after a specific step. This will show modal dialog that halts execution and allows you to inspect the state of the test right at that point. This is configurable on each step.
15. Browser agnostic Style-Color Validation: The designer now uses a browser agnostic style validation mechanism that abstracts out the different color persisting formats between IE and Firefox (i.e. rgb(r,g,b) vs #xxxxxx or named colors)
16. Tons of bugs fixes specifically the IE Blank Page issue: We fixed the IE extension to work seamlessly now. Keep in mind that if you are running:
1. Vista : You still need to disable "Protection Mode"
2. Windows 2003/2008 Server: Uninstall the "Internet Explorer Enhanced Security Configuration"
   
   

We really encourage you to try this updated build. If you have any feedback please don't hesitate to email us at CONTACT _AT_ ARTOFTEST.COM.

Note to WebAii Framework Users: The designers install RC2 of the WebAii Framework. This build includes tons of bug fixes and feature enhancements described here:

Enjoy!

ArtOfTest Team.

WebAii Design Canvas 1.0 Beta - Now supported on all VS Team System SKUs + VS Pro

We've had several customers raise the issue of our setup blocking if "VS 2008 Team System - Test Edition" is not installed. Many were using the Developer Edition or even VS Pro.

After reviewing all the VS 2008 APIs that Pro and the rest of the VS Team System editions expose, we confirmed that eveything we need for the designer is supported unlike VS 2005. With that in mind, we simply removed all the setup restrictions and the designer now works in full functionality on VS Professional and any of the VS Team System SKUs. The only feature that requires the Test Edition is the "WebAii Test to VS WebTest" conversion since only VS Test Edition has the WebTest type.

If you are an existing customer that already registered and downloaded the designer and wish to get the setup without the Test Edition block, simply re-download the designer setup from the link you got from us. It should be updated with a new setup without that block.

Enjoy!

Please let us know if you have any questions or concerns.

ArtOfTest, Inc.

Announcing WebAii Automation Design Canvas 1.0 (Beta)!!

We are very happy to announce the availability of our longly awaited designer\recorder. The WebAii Automation Design Canvas is the solution to many of today's tough automation challenges faced by testers and developers trying to automate web 2.0 apps.

The designer features have been meticulously designed and built after listening and learning from the industry and our WebAii customers. We've talked to many customers and we've heard their biggest pain points when it comes to web automation. We've also analyzed many webaii hand crafted unit tests to see where the repetitiveness is and what causes the tests to be fragile and prone to failures. We've also look at the most common time consuming tasks for test failure resolution and tried to address these scenarios directly in our designer. We not only wanted the designer to help you build automation faster but also help build better automation.We don't claim we have solved every problem but we believe the designer is a giant leap in advancing the test automation technologies in the market. Say farewell to the dark ages of web automation tools and say hello to the future. We really believe this tool will make software testing easier! Hopefully you will appreciate it as much as we do....

More info can be found here:

You can register and download the product from here: http://www.artoftest.com/betaregistration.aspx
Designer features in details: http://www.artoftest.com/webaiidcproduct.aspx
See our quick start videos here: http://www.artoftest.com/WebAiidcProduct.aspx?QS

We really want to hear your feedback regarding our beta. If you feel there is a missing feature or an enhancement you would like to see in the designer, please don’t hesitate to contact us. http://www.artoftest.com/contact.aspx

Thanks,
ArtOfTest Team

Changes/Fixes in V1.1

Changes/Fixed in V1.1. Post: http://artoftest.com/CommunitySite/blogs/artoftest/archive/2008/03/24/changes-fixes-in-webaii-1-1.aspx

WebAii 1.1 and Verification Patterns

Given that we are approaching V1.1 release, we wanted to give a quick preview of what to expect in V1.1. V1.1 is going to be all about bug fixes and performance enhancements in addition to few small feature sets that we think will make writing automated web tests a bit simpler. Mostly around writing verifications. Oh, V1.1 will also be natively compiled against .NET 3.5 and plugs in VS2008.

Performance: We have enhancements that span the entire framework. All our threading is now pooled to enhance machine resource utilization. We also have optimized both the Find logic and DomRefresh algorithms.

Verification: Anyone who has written automated tests knows that an automated test is only as good as its verification. Many current automated test frameworks brag about their ability to automate tests and perform actions but give very little focus to verification, us included :). BUT we have recognized that and in V1.1 we are taking steps to build facilities to enhance verification.

Let's take a look at what we have started building in V1.1:

Take for example a select drop down element on a page. Let's first assume you want to validate that a certain attribute exists on the element. In WebAii 1.0 you might have code that looks like this:

// Get my select drop down

HtmlSelect select = Find.ById<HtmlSelect>("myDropDown");



// Assert that it contains an attribute 'attr'

Assert.IsTrue(string.IsNullOrEmpty(

select.BaseElement.GetAttributeValueOrEmpty("attr")),

string.Format("Attribut does '{0}' not exist", "attr"));

Wouldn't be better if I can do:

// Assert an attribute exists

select.AssertAttribute().Exists("attr");

Now, we're talking... Much nicer... It is:

1. Less code to write.
2. By just glancing at this piece of code I know that the intent is to validate an attribute hence "AssertAttribute"
3. I don't have to worry about putting in the expected/actual since the assert itself is specialized and will automatically include that information in the assert exception.
   

In V1.1, we have provided three rich assert classes that are extensions (using C# 3.0 extension methods) to the HtmlControl base class so that all the HtmlControls will get them.

Here are some examples:

// Verify a style

select.AssertStyle().Font(HtmlStyleFont.Family, "Tahoma", HtmlStyleType.Computed);



// Verify context

select.AssertContent().TextContent(StringCompareType.NotContain, "foo");

There are also specialized Asserts on HtmlSelect and HtmlTable that do specialized table and select validations for example:

// Select: Validate the selected index

select.AssertSelect().SelectedIndex(NumberCompareType.GreaterThan, 3);

Or...

// Table : Validate column count

table.AssertTable().ColumnCount(NumberCompareType.LessThanOrEqual, 3);

The other cool aspect of this is that we have built an extensible framework for asserts that you can use to extend some of these existing asserts or build your own asserts for your custom controls. We will dedicate another post to go over that.