Category Archives

Test Automation

Testing Stax Control Grabber is now available for download

The Testing Stax Control Grabber is now available for download from Codeplex.

Control Grabber.jpg

 

What is this thing ?

This is a generator that tries to fast track the creation of your stax control classes. To use, open internet explorer at the page you want to capture, enter a namespace and drag the cursor onto the page. You will be prompted to save the CS file to disk. The source code for the grabber  will also soon be available as well on the Codeplex site under tools.

Automation Example Test Automation Testing Watin0 comments

Testing Stax – Parkcalc sample is now available

The first, and early release of testing stax is now available, very much a work in progress, The Parking calculator sample is a full end-to-end stack which uses to drive an Australianised version of parkcalc.

Full walk though video to come shortly. You can download the sample from codeplex here.

Test Automation Testing Watin2 comments

A peek behind our curtain

I am pretty proud of our WatiN stack, it is in it’s third major version now and is an absolute joy to work with.

After seeing some other’s code samples online I thought that I should share some of the details so people can improve what they are doing. We recently hit a new one day record with one of our SDE/T’s writing 72 new test cases in a single day.

How it works

Our stack is broken down into four key layers, the test, a logical layer, a physical layer and then WatiN itself. If we are working on a Winforms application, we replace WatiN with an in-house developed stack that uses the Windows UI automation API’s. Our test data is stored in a SQL express database and we have a generated data access layer, which keeps the cost of creating CRUD methods very low. One of our tests looks like this:

[TestMethod]
public void VerifyCustomerCreation()
{
    Logical.Customer.CreateNewCustomer("Default Customer");
    Verification.Customer.VerifyCustomerCreated();
}

And that’s it. The tests are written in the business domain of the application that we are testing, not in a pile of clicks and set values. The next level down the “logical” layer is called by the tests and looks like this:

public static void CreateNewCustomer(string customerName)
{
    Physical.Customer.GoToNewCustomerPage();
    Physical.Customer.EnterNewCustomerInfo(customerName);
    Physical.Customer.SaveNewCustomer();
}

We build our logical layer up by combining smaller atomic actions, this allows us to heavily use the DRY (don’t repeat yourself) approach.

Our physical layer is where the rubber hits the road and it looks like this:

public static void EnterNewCustomerInfo(string customerName)
{
    ControlHandler conroller = new ControlHandler();
    TestData.Customer customerDetails = TestData.Customer.GetCustomerDetails(customerName);</p>

<pre><code>controller.SetValue(NewCustomerPage.txtFirstName, customerDetails.FirstName);

controller.Invoke(NewCustomerPage.btnSave);
</code></pre>

<p>}

The control handler fully abstracts WatiN, or another automation tool so we interact with any control by typically only calling either SetValue, Invoke or GetValue.

To define our controls we have an in-house developed tool where we drag a magnifying glass (Spy++ style) onto a page and it then captures all the controls and gives us a generated static class.

This stack is the result of a lot of investment in our time and represents, in my opinion, state of the art when it comes to web test automation. But then again, I am a bit biased because I wrote it :-).

Test Automation Watin4 comments