Steve Trefethen
Contact me
About Me View my LinkedIn profile

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

Spread Thunderbird

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.

TestComplete Keyword Testing Online Training

I will be presenting a three day webinar April 12-14th 2010 from 9am-1pm PST on AutomatedQA's TestComplete. The cost is $499/person and you can register on Falafel Software's website here. For detailed information on this training click here.

Organizing your build process

November 19 2007 6:42AM

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:

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags: , , , , ,

Automated testing of ASP.NET web applications using Selenium

July 31 2007 8:06AM

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#:

using System;
using System.Text;
using System.Text.RegularExpressions;
using System.Threading;
using NUnit.Framework;
using Selenium;

namespace SeleniumTests
{
    [TestFixture]
    public class NewTest
    {
        private ISelenium selenium;
        private StringBuilder verificationErrors;
        
        [SetUp]
        public void SetupTest()
        {
            selenium = new DefaultSelenium("localhost", 4444, "*firefox",
                              "http://localhost:4444");
            selenium.Start();
            verificationErrors = new StringBuilder();
        }
        
        [TearDown]
        public void TeardownTest()
        {
            try
            {
                selenium.Stop();
            }
            catch (Exception)
            {
                // Ignore errors if unable to close the browser
            }
            Assert.AreEqual("", verificationErrors.ToString());
        }
        
        [Test]
        public void TheNewTest()
        {
            selenium.Open("/selenium-ide/");
            selenium.Click("link=About");
            selenium.WaitForPageToLoad("30000");
        }
    }
}

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!

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags: , , , , , , , , ,

I'm gathering issues upgrading from earlier versions to Delphi 2007

April 16 2007 6:02PM
NOTE: The focus here is on the process of upgrading applications not simply upgrading the IDE.

If you've upgraded from any earlier version of Delphi to Delphi 2007 please leave a comment here as to what, if any, issues you encountered porting exsiting applications. I'll work to collect them and get them organized and more searchable so more people can benefit.

Please try to include as many specifics as possible. If you'd rather send me an email at strefethen at codegear dot com and I'll integrate that as well.

I'm interested in issues related to things like:
  • Installation/configuration
  • RTL source code related changes
  • VCL component changes which may affect older applications
  • OpenTools API changes
  • Rebuilding 3rd Party component libraries
  • Recompiling existing applications

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags:

Delphi 2007 Component Palette Improvements

March 04 2007 5:07AM
Recently, Jeremy North, Marco Zehe and Primoz Gabrijelcic have all blogged about some great tool palette enhancements in the Delphi 2007. One item I haven't seen mentioned is better keyboard support. Since the Tool Palette is now organized like a treeview, albeit a two level treeview, we felt it should support similar keyboard navigation. Marco Zehe pointed out that categories are now selectable but additionally you can use all the normal treeview keystrokes to expand/collapse categories and navigate the palette which is much more consistent UI.
Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags:

Improving Delphi documentation

December 11 2006 7:43AM
I'm a big fan of The Daily Grind and a post from Friday Mike linked to this blog post which talks about Microsoft adding wiki like support to MSDN online documentation. I'm hoping that moving towards online documentation that supports some level of community contributions is an area in which CodeGear can distinguish itself.

Back when I was in QA I wrote several automated GUI test suites to test Delphi documentation including all IDE dialogs as well as all properties, methods and events for the VCL/RTL. The suite launched the help (then WinHelp), selected all of the content then copy it to the clipboard so it could further verify that the expected content was retrieved. The test covered properties, methods and events (PME's) by parsing the Pascal source code, using a Pascal based parser originally written by Anders Hejlsberg, and keying each PME into the code editor and pressing F1. The test would then search for the declaration of the PME in the help and compare it to what the parser had found to verify that the correct page appeared and that the declaration matched.

I worked closely with a few of the doc writers and in particular Janet Delu, to keep the test running and  log failures. Janet was particularly interested in VCL/RTL framework coverage did a great job filling the voids that existed. When I see people today longing for old Delphi content I think of all the work she and numerous other writers did to improve our documentation. Unfortunately, much of their effort was "lost in translation" when the doc team's management changed and the entire team turned over.

These days there is a great deal of focus on improving our documentation and everyone's aware it's a critical issue. Fortunately, documentation was identified early on during the preparation for the divestiture as needing attention and numerous positions where opened and the rebuilding process begun. In fact, I have a meeting on Monday with a new writer to go over some VCL documentation.

Fixing the documentation won't happen overnight though it's one area among many where I see CodeGear having a huge affect.

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags:

Development using Agile

November 24 2006 10:55PM

Since the beginning of the Highlander (vNext BDS) development cycle the team has been using Agile and at this point, it's safe to say I'm still on the fence about it. The decision to use Agile wasn't quick nor was it made on the first day of the project, rather it came after numerous discussions and actual training sessions with an Agile instructor/consultant. Now, I'm not blaming the consultant and in fact, if anything the instruction was useful for us to improve our development process for reasons unrelated to learning Agile. I believe there are projects which would/could benefit from a strictly Agile approach however, given our team size, the disparate skill sets our staff has, the size and complexity of the IDE I think we're likely to have to reexamine and adapt our use of Agile which isn't a surprise and I'm sure at least some people in the Agile community would say that that's what Agile is all about.

Prior to this year I'd say our development process was a modified version of waterfall which has seen it's ups and downs. One point I'd make though is that when there are changes in the engineering staff, the technology, the market, the business and the management is it fair to blame the process when things go wrong? I'll be the first to admit our process can and needs further improvement and we're committed to and actively working on those improvements today. In fact, I've blogged a lot about our development process much of which has evolved even since last year and not just because of our use of Agile.

Like most engineers my team has lots of ideas about how things could be improved and in many cases those ideas are acted upon independently and our process incrementally improves. Perhaps one of the best things to come from all the focus on Agile and XP is simply the fact it has gotten engineers actively interested in thinking about the development process. Of course, it hasn't hurt that the discussion has been accompanied by lots of tools for things like unit testing and continuous integration which I believe really helps drive engineering interest.

It's interesting, I think most of the process improvements our team has enjoyed this past year occurred organically driven, not by management, but by individual engineers with a desire to utilize the maturing set of tools that are available today. I believe one critical turning point was our single minded focus on quality for the BDS 2006 release. I believe the release itself was high quality but since November of last year we've released at least seven updates more than triple what we normally ship. It's this same desire to ship quality code that has fueled much of the process changes we've put in place in the past 12 months.

I haven't really talked about why I'm on the fence about Agile and at some point I'll fill in the blanks but one thing is clear, IMO the BDS development team is actively moving in the right direction.

If you're new to reading my blog check out my Zombie posts regarding our automated testing efforts and have a look at the video I posted of our R&D smoke test for BDS.

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags: , ,

Automating popup windows and dialogs

October 26 2006 7:38AM
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.
Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Tags: ,