Powered by discountASP.NET
referal ID: sdtref
Why recommend discountASP.NET?

Archives
Steve Trefethen Steve's RSS Feed Subscribe or via email
What's this?
Contact me Send mail to the author(s)
About Me
View my LinkedIn profile

Add to Google
Subscribe with Bloglines
MCP Microsoft Certified Professional

Falafel Software
ActiveFocus Project Management Solution by Falafel Software
Online or OnSite TestComplete Training
Blogroll
Recent Comments
My Online Tools
Stats
Total Posts: 441
This Year: 46
This Month: 2
This Week: 0
Comments: 1526
Tags
Disclaimer
The posts on this weblog are provided �AS IS� with no warranties, and confer no rights. The opinions expressed herein are my own personal opinions and do not represent my employer�s view in any way.
 Tuesday, February 12, 2008

GUI models allow for compile time error detection of changes that break test automation

Posted @ 4:54AM by Steve Trefethen

Categories: Automation | Testing

Tags:  | 

When I was working at CodeGear one of the tools I wrote generated models of .DFM’s (Delphi’s form file format) for use with GUI automation. A model is a class that mirrors the control hierarchy found on a form with classes that can perform automation tasks (clicking, typing, determining location etc.) against the controls. For more information on models refer to this post.

Modeling a Form, an Example

Below is an example of a simple Delphi form and it’s corresponding model class:

Delphi Form Class Corresponding Model
type
TMyForm = class(TForm)
MessageText: TLabel;
Yes: TButton;
No: TButton;
Cancel: TButton;
...

end;
type
TMyFormModel = class(TBaseDlg)
MessageText: TLabelGem;
Yes: TButtonGem;
No: TButtonGem;
Cancel: TButtonGem;
...

end;

The model is generated off of the .DFM which looks like this:

object Form1: TForm1
  Left = 217
  Top = 88
  Width = 1082
  Height = 749
  Caption = 'Form1'
  object MessageText: TLabel
    Left = 19
    Top = 13
    Width = 32
    Height = 13
    Caption = 'Label1'
  end
  object Yes: TButton
    Left = 15
    Top = 43
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
  end
  object No: TButton
    Left = 101
    Top = 43
    Width = 75
    Height = 25
    Caption = 'Button2'
    TabOrder = 1
  end
end

Delphi’s VCL component library supports Visual Form Inheritance and since there isn’t enough contextual information to reconstruct the form’s class hierarchy without compiling the code the model generator is provided a file that contains these details so the generated models exactly mirrors the application’s form inheritance hierarchy not just the form itself.

So Why is a Model Generator Important?

At first, you might think sure, the model generator is going to save you lots of time coding which is entirely true. But, that’s not the only nor the largest benefit of using generated models. An additional benefit is that the models are compiled using a statically typed language providing for compile time error detection. For example let’s say a developer renames the "Yes" button to "YesBtn" or deletes the MessageText label?

If the model had been hand written or statically generated, which is the situation CodeGear was in, the error would only surface once the test suite had executed. At that point, log file analysis would have to be performed to distinguish between a real bug and a automation error, not a good situation to have QA people in day after day. With generated models these kinds of errors can be detected at compile time allowing for R&D to assess the impact of the change on QA’s automation and not vise versa. Btw, this also underscores the fact that the model generator can provide alias functionality thus preventing simple name changes from impacting test automation.

The faster developers can find out they’ve broken existing test suites the more likely the problem can be corrected even in the event that not all test suites are executed every build. Yet another benefit of continuous integration.

There are several other benefits like:

  • Give R&D the ability to determine the impact a given change will have on the existing test automation
  • Provide insight into the depth of testing through static code analysis and evaluating which models as well as which parts of models are being exercised
  • Allow R&D/QA to quickly automate new UI

Conclusion

Backing your GUI testing with compile time error checking allows you to leverage GUI test automation in several ways. In addition, a development team will have much more visibility into the impact a given change will have on the existing test automation as well as provide insight into areas that need additional testing.

It’s a shame the test framework developed at Borland starting back in 1994 has never made it into the hands of developers outside the company. Perhaps I should look to start an Open Source project for model driven testing using C# based on  IAccessible. Btw, I just Googled on IAccessible and the post I linked to is in the top ten, meaning this advice really does work.

See also: Automation

 Sunday, December 30, 2007

Microsoft's ASP.NET MVC framework will be great for Automated UI testing

Posted @ 10:12PM by Steve Trefethen

Categories: ASP.NET | Automation | Testing

Tags:  |  | 

I’ve written automated UI tests using Selenuim running against a large ASP.NET Web 2.0 ERP application with great success. However, IMO the single biggest productivity killer for writing such tests is ASP.NET WebForms ID name mangling where ID’s are changed from something like "lblSysMText" at design time to "ctl00_cphContents_dlMessages_ctl01_lblSysMText" at runtime. Fortunately, Selenuim supports the use of XPATH expressions so searching for the above tag can be done using the following:

//span[contains(@id, "lblSysMText")]

Name mangling is a huge problem and thwarts all sorts of automated test tools whether you’re using AutomatedQA's TestComplete or a something like Selenuim. Whenever you have a situation where a simple containership change like moving a control into a DIV can break an automated test you’ve got a problem. These sorts of changes occur all the time on WebForms which are actively being developed meaning unless your tests are written using a partial match logic, like what I’ve illustrated above, you’ll be faced with lots of bogus failures which not only kill productivity but undermine your test automation efforts as the tests will be viewed as fragile and a waste of time.

MVC to the Rescue

Scott Guthrie wrote:

This model view controller (MVC) framework for ASP.NET provides a structured model that enables a clear separation of concerns within web applications, and makes it easier to unit test your code and support a TDD workflow. It also helps provide more control over the URLs you publish in your applications, and more control over the HTML that is emitted from them.

With the MVC framework name mangling will be a thing of the past. I believe not only will the MVC framework make unit testing easier it will be a major win for automated UI testing for ASP.NET apps. You’ll no longer have to jump through hoops to figure out the ID of a given tag on the page.

Last but not least, with MVC style development you’ll finally be able to use ID’s like #lblSysMText in your CSS again.

 Sunday, November 18, 2007

Organizing your build process

Posted @ 10:42PM by Steve Trefethen

Categories: Automation | Continuous Integration | Development | Quality | Testing | Tips

Tags:  |  |  |  |  | 

In this, my second post in a series on automated testing, I’m going to talk about a few steps you’ll need to take after your team has committed to automation. Diving into the deep end and immediately writing a bunch of tests isn’t the place to start. Organizing your project, preparing your code base and planning for automation are the first priorities. Of course, the assumption here is that you’re adding automation after the fact.

Organizing your build

If your project isn’t easy to build you’ve identified the first thing that needs fixing. Having a repeatable automated build is key to a successful test automation strategy. Essentially, getting your build organized means the following two things:

  • Version control
  • Continuous Integration

Version Control

Subversion
The first step to organizing your build and preparing it for continuous integration is to make sure it’s under version control. There are lots of ways to implement version control but it’s the first step to repeatability which is what test automation is all about. Personally, I really like SubVersion otherwise known as SVN, and would highly recommend it particularly if you’re just starting out. There’s been plenty written about the benefits of version control so I won’t go into that here just make your choice and get your code checked in.

Build Automation

The next step is automating your build process. Jeff Atwood wrote The F5 Key Is Not a Build Process discussing the benefits of moving your build process beyond your IDE of choice and I couldn’t agree more. Build automation is really going to be the key to successful test automation. When changes are committed to your repository a build gets kicked off and subsequently launches your test automation. With this setup you’re automation is guaranteed to run against every change to your repository immediately notifying you when a change has "broken" the build.

Note: Make sure your team understands that a break in test automation that’s kicked off as part your continuous integration process is as bad as checking in a syntax error. Yeah, read that again. Even if the code builds, if the smoke test fails as a result of the check-in it should be treated as though a syntax error were checked in.
cruisecontrol.net
For continuous integration I’m a fan of CruiseControl.NET but as with source control you have a lot of choices. CruiseControl.NET is open source and includes a web dashboard that’s easy to modify and supports writing plugins making it easy to extend the build system. Its rather light on documentation so if you don’t want get your hands a little dirty I’d recommend something like Automated Build Studio from AutomatedQA.

 

Putting it all Together

If you find this to be a bit daunting, have no fear I’ve put together a 10 minute video that demonstrates this entire process from beginning to end for a simple project. Of course, your project will be more complex but you’ll get a feel for how easy it is to get going. Note, I made this video in April '07 while still employed at Borland which is no longer the case nonetheless the video is still relevant.

Previous entries in this series:

Other related posts I’ve written:

 Wednesday, November 14, 2007

Automated testing advice - making the commitment

Posted @ 12:18AM by Steve Trefethen

Categories: Automation | Testing

Tags:  | 

Over the years I’ve spent a great deal of time writing test automation and I’ve learned a lot along the way. The road to successful automation has lots of steps, some small some large. I’m going to start a series of posts talking about my experience with test automation dating back to 1994 when I got my first serious taste.

Commit to automated testing

Ensure that everyone in your team who you want involved in test automation is committed to its success. If you can’t do that then you’re looking at an up hill battle that commit themselves to building and maintaining a automated test environment consider the battle lost.

Team Commitment

For automated testing to succeed you have to gain buy-in from all the involved parties and through hard work validate that automation can benefit everyone. Here are some of the initial things you’ll need to get your team to commit to:

  • Learning about software testing
  • Buying, building or finding open source tools your people can embrace for use in automation
  • Monitoring the success of the testing efforts
  • Developing a smoke test
  • Sharing the responsibility of maintaining the smoke test
  • Creating a command line build for your project(s)
  • Publishing test results

Individual Commitment

As an individual contributor if you’re not willing to commit time and effort to learn and assist with your team’s test automation efforts you’re undermining the process.

  • Always considering how your code will be tested
  • Learning the tools and techniques available to test your code
  • Writing tests for your own code
  • Run the smoke test before checking in
  • Understanding how changes you make will impact existing tests

Of course, these aren’t exhaustive but if you can’t accomplish these tasks the likelihood of succeeding will dwindle rapidly. I’ll look to expand on a number of these items.

Let’s face it, test automation can be hard and convincing people that it can save them time and effort can be equally difficult. If you’re team isn’t already on the testing bandwagon then you’re likely in a situation where you’re going to have to prove that automation can work before you’ll receive greater buy-in so be prepared to go it alone in the beginning. Committing to automated testing, in particular, convincing your clients and management may be a difficult task so be prepared.

What sort of problems have you run into getting people to commit to test automation?
 Tuesday, July 31, 2007

Automated testing of ASP.NET web applications using Selenium

Posted @ 1:06AM by Steve Trefethen

Categories: .NET | AJAX | ASP.NET | Automation | Continuous Integration | Firefox | IDE | Open Source | Quality | Recommended | Testing | Tools

Tags:  |  |  |  |  |  |  |  |  |  |  | 

Lately, I've been focused on Web Application testing frameworks and I've been looking at a number of different options and having varying degrees of success. That is, of course, until I started looking at Selenium after Lino mentioned it to me and I'm very impressed. Selenium is an open source project with multiple tools designed for testing web applications. Selenium includes:

  • Selenium IDE an add-on to Firefox use for recording test scripts
  • Selenium RC (Remote Control) a Java server used for execution of test scripts
  • Selenium Core client side testing support for web applications added directly to your application
All of these are interesting in their own right so be sure to look closely at each piece.

Selenium IDE

Selenium IDE
The Selenium IDE is a non-modal dialog add-on for Firefox that supports Selenium test development. In fact, it's more than fair to call this single dialog an IDE because it fully supports recording, development and debugging of test scripts. Additionally, it can format test scripts in any of the following for use with Selenium RC:
  • HTML
  • Java
  • C#
  • Perl
  • PHP
  • Python
  • Ruby

A Selenium test script consists of a series of Commands which have a Target and optionally a Value. For example, browsing to a web page using Selenium consists of the following:

Command: open
Target: http://localhost/myapp

To click on a link titled "About" on a page the Command might look like this:

Command: clickAndWait
Target: link=About

This will initiate the click and wait until the new page is done loading. There are literally hundreds of commands to choose from covering input (both keyboard and mouse), control manipulation, drag/drop, evaluation, verification, waiting, browser manipulation and just about anything else you'll need.

If you've done any UI testing at all you're familiar with the challenge of manipulating a UI programmatically in a manner independent from of the size, position or location of the control you're trying to manipulate. Selenium solves this problem using XPATH and providing the ability to locate controls based on XPATH expressions alleviating the need to hard code HTML tag structure into a test script. This is particularly crucial for ASP.NET testing since the runtime mangles the ID attributes of rendered tags. For example, the ASP.NET runtime may render ID attributes that look like:

id="ctl00_cphContents_gridMaint_DataGrid"

Finding this control using an XPATH expression can be simplified to something like this:

//table[contains(@id, "gridMaint")]

In the event the nesting of the DataGrid changes the script will continue to function properly as long as table's ID contains the text "gridMaint".

Example of using the Find button on the Selenium IDE

Notice the link is highlighted in the browser

Playing back tests using Selenium TestRunner

The Selenium IDE has a toolbar button that will launch a feature called TestRunner which allows you to playback your tests using controls hosted in an IFRAME inside your browser. Here's what it looks like:

Selenium TestRunner

You can playback your entire test from right within your browser. It's like having the IDE built right into your application.

Selenium RC

Next, is Selenium RC which is a Java server application used execute Selenium tests and drive a browser instance through AJAX communication with the browser. To start Selenium RC simply execute the following from a command prompt:

java -jar selenium-server.jar -interactive

Since I'm focused on .NET I'll discuss the C# approach. Once you've recorded and debugged your test you can capture it as C# and compile it into an NUnit compatible assembly where upon execution it will drive Selenium RC to manipulate the web application through a browser instance running on your desktop. Here is an example of the above recorded test in C#:

1 using System; 2 using System.Text; 3 using System.Text.RegularExpressions; 4 using System.Threading; 5 using NUnit.Framework; 6 using Selenium; 7 8 namespace SeleniumTests 9 { 10 [TestFixture] 11 public class NewTest 12 { 13 private ISelenium selenium; 14 private StringBuilder verificationErrors; 15 16 [SetUp] 17 public void SetupTest() 18 { 19 selenium = new DefaultSelenium("localhost", 4444, "*firefox", 20 "http://localhost:4444"); 21 selenium.Start(); 22 verificationErrors = new StringBuilder(); 23 } 24 25 [TearDown] 26 public void TeardownTest() 27 { 28 try 29 { 30 selenium.Stop(); 31 } 32 catch (Exception) 33 { 34 // Ignore errors if unable to close the browser 35 } 36 Assert.AreEqual("", verificationErrors.ToString()); 37 } 38 39 [Test] 40 public void TheNewTest() 41 { 42 selenium.Open("/selenium-ide/"); 43 selenium.Click("link=About"); 44 selenium.WaitForPageToLoad("30000"); 45 } 46 } 47 } 48

Generation of NUnit compatible tests is great because it makes it really easy to incorporate Selenium test suites into a continuous integration environment like CruiseControl.NET.

Conclusion

If you're in need of a web application testing framework you owe it to yourself to check out Selenium. I'd go so far as to say if you're doing doing any web related development and you're not already using Selenium you should stop right now and go download it. Here are there RSS feeds.

After playing with Selenium for about an hour I was easily able to:

  • Record tests against a RIA
  • Build a C# NUnit compatible assembly to drive Selenium RC
  • Integrate the tests into an automated build using CruiseControl.NET

Since then I've been able to really dig in and accomplish a lot of work in a very short period of time. The next step is to build up a nice battery of tests and dig into NCover to help figure out where the holes are.

Lastly, I just want to tip my hat to the ThoughtWorks and volunteers and supporters of the Selenium project. Kudos for such a great framework!

 Thursday, July 26, 2007

Diving into web application automated testing

Posted @ 10:14AM by Steve Trefethen

Categories: AJAX | Automation | Testing

Tags:  |  | 

My new job is completely focused on ASP.NET development and being a big believer in automated testing I've been investigating strategies for RIA's. I've found what I think is going to be a solution using Selenium which I'll blog more about later though I'm curious to know what other frameworks people are using? Basically, I don't want to overlook any potential candidates though at this point I'm very happy with Selenium.

What are you doing for automated testing of AJAX enabled Internet applications?
 Friday, May 18, 2007

Code to help generate MSBuild compatible output

Posted @ 1:34PM by Steve Trefethen

Categories: Automation | Tools

Tags:  | 

MSBuild console output

When the Delphi team switched it's build process to MSBuild and started running Zombie under a Continuous Integration Environment the test automation framework also had to be updated to output MSBuild style errors. MSBuild recognizes errors which follow a specific format allowing it to colorize them as well as report them back to the calling process. Without proper error formatting MSBuild will simply continue merrily along without the slightest clue something might have failed.

Here is a zip file that contains a small Delphi unit which implements an MSBuildStr function with multiple overloads to help you create MSBuild compatible output. The zip also contains a simple console application which illustrates calling the MSBuildStr functions and a MSBuild .proj file that allows you to test the output. This unit doesn't cover every single form of MSBuild style output but it does cover some of the most common uses. To test the sample console app:

  1. Extract the contents of the zip file to a directory if your choice
  2. Build OutputTest.dpr
  3. From a command prompt CD to the above directory and execute:

    %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe make.proj
You should see output similar to the above picture. Feel free to use/change/improve/tweak this code however you like.
 Sunday, April 15, 2007

CCNetConfig to help you create and maintain your CruiseControl.NET server

Posted @ 9:48PM by Steve Trefethen

Categories: Automation | Continuous Integration

Tags:  | 

CCNetConfig
Now that you've run out and setup CruiseControl.NET and started using Continuous Integration for your Delphi Win32 projects you may be interested in CCNetConfig which is a tool to help you maintain your CruiseControl.NET ccnet.config file. This is a nice repreve from having to hand edit this XML file using just the available online help. Don't get me wrong that's no slam against the documentation which I've used countless times and is very good but a tool like this is very much appreciated.
 Tuesday, April 10, 2007

Video: Setting up a continuous integration environment

Posted @ 12:37PM by Steve Trefethen

Categories: Agile | Automation | Delphi | Development | Open Source | Testing | Tools | Videos

Tags:  |  |  |  |  |  |  | 

I've blogged a lot about how CodeGear uses Continuous Integration (CI) in it's development process for Delphi/BDS. What want to talk about here is how you can use these same tools for your development process.

First, is the issue of version control and for that we use Subversion otherwise known as SVN. SVN is open source and fortunately there is a convenient "1 click setup" described as follows:

Svn1ClickSetup takes a user through the steps necessary to install the Subversion command-line utilities and TortoiseSVN, as well as creating a repository and initial project.

This setup really lives up to it's name so if you're looking for a fast and easy way to get started with some great source control software this is what you're looking for. The install includes the TortioseSVN client which is an SVN client that's implemented as a Windows Shell Extension and is what the majority of developers at CodeGear use.

A Continuous Integration Server

That may sound a bit more daunting than perhaps it should but basically it's the software that pulls from your repository, builds your project and reports any errors. The Delphi development team uses CruiseControl.NET server and CCTray for client side notifications of build failures both of which are open source projects and even though it has ".NET" on the end of its name the server isn't restricted to building .NET only projects.

Once again the installation is very straight forward and if you have IIS installed you'll even be able to monitor your CI server via a browser including forcing a new build.

Ok, now that you've read all about it have a look at the video. Or can download it here.

Here is the ccnet.config file used in the video, and no, "steve" is not my normal password. :-)

[UPDATED: April 23, 2007] Fixed video and .zip file download links.
 Tuesday, January 09, 2007

Developing GUI test automation for a Continuous Integration environment

Posted @ 7:43AM by Steve Trefethen

Categories: Agile | Automation | BDS | Delphi | Zombie

Tags:  |  |  |  | 

Last October I blogged about GUI testing being hard and I meant that without the requirement of running as part of a Continuous Integration (CI)environment. Performing GUI automation within a CI environment imposes it's own unique challenges where tests have to be able to:

  • Handle all cases where the GUI app fails to shutdown properly
  • Handle unexpected UI from the GUI app (crash dialogs, Windows fatal error dialogs etc.)
  • Terminate the application if it takes too long to respond
  • Log output in the CI environments desired format (we had to add MSBuild output support to our test framework)

Additionally, the CI environment itself must allow GUI application execution. We're using the console version of CruiseControl.NET so we can monitor the status messages that appear. The console version presents a bit of a unique problem in that all output is captured so we're not able to see the test output during execution.

It's been 83 days since the aforementioned post and 790+ CruiseControl.NET builds (not all of which succeeded) and our GUI automation is humming along nicely. The test has caught numerous problems along the way and improved the overall quality of builds getting to QA. The QA smoke test, the first test QA runs on a build to determine if it's worth further inspection, has also been consistently passing at 100% for quite awhile now and it too is catching failures and saving valuable QA time and resources.

Of course there are many factors which have contributed to the overall success rate of our testing efforts for example:

  • First and foremost we fixed 1,000's of bugs in BDS 2006 including the numerous patches we've released
  • We committed R&D resources to improve and maintain our test framework
  • The model generator I mentioned here which allows us to have up-to-date models with each build
  • We've enabled R&D to develop their own GUI tests suites
  • We're leveraging virtual PC's to quickly and consistently test a broad range of IDE/VCL features

One of the coolest Zombie tests I've ever seen is one written by Chris Hesik a few months ago. It tests both the managed and unmanaged debuggers by debugging the IDE in itself. The test:

  1. Starts the BDS IDE
  2. Loads a copy of it's own project group
  3. Recompiles all of the packages from the entire IDE then the BDS.EXE
  4. Sets breakpoints in the code
  5. Launches BDS IDE under the debugger
  6. Tests all sorts of debugger functionality
Now, that's a serious test! Above is just a brief summary of steps and hardly does justice to all of the work the test actually performs but if you've ever written GUI automation I'm sure you can appreciate what's involved in testing two copies of the same application where one instance is debugging the other not to mention running under CI. Chris and I spent quite a bit of time going over the finer details of how this was all going to work and I have to say he did a fabulous job of putting it all together. I'll ping him and see if perhaps he can write a blog post about it.
 Monday, December 25, 2006

Are you using DUnit to test your Delphi applications?

Posted @ 11:58PM by Steve Trefethen

Categories: Automation

Tags:

If you've been reading my blog over the past few months you'll know that I've written a number of posts related to automated testing. We have our own internal test automation framework so I've never really taken a close look at DUnit although having browsed around the SourceForge page for DUnit I'm wondering if the project is still alive/active? This post mentions an update for D2006 back in August stating that a "release version will follow in a few weeks" although the SourceForge pages for DUnit seem very quiet and the bug tracker doesn't have any recent issues logged against the core. Not to mention that it's obviously been more than a few weeks since August 1st, which has me wondering what the state of DUnit really is?

Our internal testing framework has a class called TTestManager, written prior to Delphi 1.0, which manages test execution and handles the "accounting" details like how many tests have executed/passed/failed. One of the design goals was to use as small a footprint of the Delphi RTL as possible to give it the best chance to compile and run in the midst of a changing compiler and RTL. Over the years TTestManager has lived up to this goal and served its purpose well though, I think it's a bit long in the tooth and it may well be time to use something like DUnit. There are a few developers here who have experience using it and I need to sit down with them and get their opinions. One of the biggest problems we have with our tools relates to reporting and the ability to publish test results to the entire team. Again, over the years there have been a multitude of solutions though none of which have been overly effective.

So, this leaves me with the following questions:

  • Is the DUnit project still alive?
  • What is your impression of DUnit?
  • What, if any, changes they would make to it?
  • Are you comfortable writing tests with DUnit?
  • How do you publish the results of your testing efforts?
FWIW, in January I plan on spending a little time investigating DUnit to see it's something we should look more closely at.

 Saturday, December 09, 2006

Using VMware and CruiseContro.NET on a Dell XPS 670 workstation

Posted @ 2:21PM by Steve Trefethen

Categories: Automation

Tags:

A few months ago I was able to order a new machine at work, a Dell XPS 670 workstation. It's a pretty serious workstation and in fact, around the office we've been calling these boxes "our mainframes". Mine has two dual core Intel Xeon CPU's with 4GB of RAM and two 250GB 7200 RPM hard drives configured using RAID 0.

Keeping this machine from idling all the time can be a difficult task so I just setup a VMware player running Windows XP SP2 Pro using CruiseControl.NET to run our ASP.NET smoke test. The VM runs minimized in the taskbar and builds whenever the source repository changes. At this point, CruiseControl has been running for 2 days and built and run the smoke test successfully 28 times.

I figure this should help chew up some of these spare cycles

 Friday, November 03, 2006

Do you do automated GUI testing? If so, what tools do you use?

Posted @ 10:48AM by Steve Trefethen

Categories: Automation

Tags:

I've talked a lot about our internal testing framework which we've developed ourselves for automating the IDE. I'm curious though:
  • Do you do any automated testing?
  • What tools do you use for VCL testing?
  • How successful have you been in your GUI testing efforts?
 Thursday, October 26, 2006

Automating popup windows and dialogs

Posted @ 12:38AM by Steve Trefethen

Categories: Automation | Quality | Zombie

Tags:  |  | 

I've been discussing Zombie, our internal testing framework and last time I talked about generating and using models which are classes used to drive a UI. Previously, I gave an example of a simple model that had a constructor called Connect. One reader, Eric Fortier commented asking how is the Connect constructor used? That's a really good question.

The Connect constructor is a model specific override that looks like this:
constructor TMyFormModel.Connect;
begin
  inherited ConnectTo('TMyForm', nil);
  Init;
  Bind;
end;
Of course, the next question is what does ConnectTo do? Well, as you can see it takes the classname of the form that's modeled, the second parameter is for the caption but typically it's not required so for  generated models it's always nil. The ConnectTo constructor uses a special "wait" function which is similar to the Windows FindWindow API call but has the ability to continue searching for a window for a period of time before giving up or timing out. In fact, our framework has a whole set of Wait routines that use our own FindWindow replacement built on top of EnumWindows and EnumChildWindows that supports things like partial matches on window captions and limiting the search to only windows which  are visible to name only two.

Once the window in question has been located the model initializes all of the GEMs, or individual component models necessary to drive the windows various UI elements then calls Bind. The Bind method hooks up the mechanism used for the model to inspect the Window at a deeper level for example the RTTI of the object that instantiated the window. Binding to a window is a complicated process and it's where the real power of the Zombie framework together with the VCL framework is  derived.
 Monday, October 23, 2006

Modeling UI for automated GUI testing

Posted @ 9:10PM by Steve Trefethen

Categories: Automation | Delphi | Zombie

Tags:  |  | 

If you've been following my blog recently then you're already familiar with the name Zombie and that it's based on this patent. The part that I'm going to touch on in this post is relates to this sentence from the "Summary of the Invention":
"The system includes a Generic Element Models (GEMs) library,
Application-specific Testing Models (ATMs), a Resource Database, one or
more Model Generators..."
Like VCL one of the most powerful features of Zombie is its set of core GEM classes. A GEM is a class that provides the ability to inspect its VCL counterpart at runtime using RTTI as well a mechanism similar to class helpers as well as interact with the component via the mouse and keyboard. However, just like individual VCL components GEMs really aren't all that useful unless you combine them just like you do when you drop VCL components onto the form designer. Since GEMs have no visual representation themselves we turn to model generators to do the heavy lifting and produce classes that mirror entire VCL Forms using various GEMs to represent the components on the form. Here is an example of a simple VCL form and what a model for it might look like:

type
TMyForm = class(TForm)
MessageText: TLabel;
Yes: TButton;
No: TButton;
Cancel: TButton;
end;
type
TMyFormModel = class(TBaseDlg)
MessageText: TLabelGem;
Yes: TButtonGem;
No: TButtonGem;
Cancel: TButtonGem;
constructor Connect; override;
procedure Init; override;
end;
Given the above model you could use it as follows:
var
AMyFormModel: TMyFormModel;
begin
AMyFormModel := TMyFormModel.Connect;
try
Writeln(AMyFormModel.MessageText.Caption);
AMyFormModel.Yes.Click;
finally
AMyFormModel.Free;
end;
end;
This example illustrates the inspect capabilities of a GEM with code like MessageText.Caption as well as the automation capability using methods like Yes.Click where the click method internally inspects the size and location of the button and correctly determines where mouse down/up events need to occur to execute a mouse click. The implication here is that models are resolution independent and therefore suites written with Zombie can run on any resolution which is exactly the case.

We use a model generator for the IDE which generates roughly 1000 models of various forms/frames from DFMs used throughout the product. These models reflect any Visual Form Inheritance used within the forms and therefore provide a deep toolbox for suite developers to leverage and drive nearly all aspects of the IDE.
 Friday, October 20, 2006

Driving the keyboard and mouse for test automation

Posted @ 9:35AM by Steve Trefethen

Categories: Automation | Quality | Zombie

Tags:  |  | 

I've mentioned Zombie a number of times, our internal GUI automation tool, and one of its core features is that it drives the GUI the same way a user does, via the keyboard and mouse. Zombie is designed to mimic normal user input by driving the UI under test using the low level keybd_event and mouse_event Windows API's. The design is intentional and prevents testers from writing automation that would manipulate a UI in ways not available to a human user. This gives us
  • assurance that if Zombie reproduced a problem a user could too
  • dramatically improves the chance of manually reproducing whatever problem was encountered
As a result for a test writer it's important to understand exactly how Zombie manipulates the GUI to give them the best chance of reproducing the same problem manually. In fact, recently I've started a page on our internal wiki which explains the internal workings of Zombie so that our QA staff has a better chance at reproducing any problems.

Back in 1994-5 when Zombie was first implemented it leveraged a DLL from Microsoft Test to handle the driving the keyboard and mouse but when we moved to Win32 in the Delphi 2.0 timeframe we had to replace the DLL with our own code that worked on Windows NT. In fact, even today the Delphi Unit that contains all of our core mouse and keyboard routines is called MSTest.pas. I sort of laugh when I open this file and see the PVCS comments at the top where my earliest comment reads:
 *    Rev 2.6   12 Jul 1995 12:42:02   STREFETHEN
* Added a functions that provide mouse click support for TreeView and Header
Ah, now those were the good old days!

Update: I almost forgot, I recently posted a Flash movie of Zombie running against Highlander here.
 Wednesday, October 18, 2006

Screencast of Windows Test Automation of the BDS IDE

Posted @ 9:10AM by Steve Trefethen

Categories: Automation |