Modeling a Form, an Example

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

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?

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

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

The following outlines the steps I took to demonstrate how easy it is to setup and execute HTTP load tests.

Setting up an HTTP Load Test Project

1. Select File | New Project
2. Click the HTTP Load Testing Template
3. Click Ok
4. The Project Wizard appears and you can simply click Finish which will give you a project that looks like the image to the right.

As you can see the project has several nodes by default.

• Stations: represents the machines that will be conducting the tests. Master is my current machine, the one I'm running TestComplete on.
• Tasks: is the HTTP traffic you’re interested in testing.
• Tests: allows you to assign tasks to various stations for test execution.
• Scripts: is for manually writing test automation.

Setting up Remote Agent

The next step is to setup the machines you’ll use for load testing under the Stations node of your project.

1. Right click the Stations node and select Add New... (you should see the dialog to the right)
2. Enter the IP address of your Remote Agent machine, in my case that’s 192.168.1.104.
3. Click Ok

This will give you a new node under Stations, "VPC" which is your VM, or the machine running Remote Agent.

Record an HTTP Task

1. Configure Internet explorer to use TestComplete as a proxy allowing it to monitor and record HTTP traffic. For IE you can do that from the Connections tab of the Internet Options dialog setting the proxy to localhost on port 9999. For Firefox open the Tools|Options dialog and look on the Advanced page, under the Network tab.
2. Click the record button on the TestComplete toolbar and once recording begins click the "Record and HTTP Task" button (circled in red below):
   
3. This will bring up the Select Load Testing dialog where you can decide to record a new HTTP traffic or append it to an existing task.
4. Once you click OK you can begin recording HTTP traffic by simply using your browser. TestComplete will record the HTTP traffic and add it to the task you specified.

Once recorded you can modify the web requests to fit your needs. Here is an example of what the recorded HTTP traffic looks like:

Running HTTP Load Testing

As you can see I’ve configured one virtual user to sent HTTP traffic starting half a second after the Master with a User-Agent of IE6.

Running HTTP Load Testing

Wrap up

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:

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.

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

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.

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:

• Automated testing advice - making the commitment

Other related posts I’ve written:

• Automated testing of ASP.NET web applications using Selenium
• Developing GUI test automation for a Continuous Integration environment
• Modeling UI for automated GUI testing
• Automated testing of Windows applications is hard

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.