Writing QTP Tests in Visual Studio

Background

It’s no secret I’m not a fan of QTP’s code-editor – it lacks intellisense, meaningful autocomplete, code folding, and many other “Must” features; And while QTP 10 will improve the situation, the IDE’s core problems will remain. In addition to the IDE’s shortcomings, QTP’s reliance on VBScript cripples it in many key areas such as object-oriented programming (tests, actions and GUI classes could inherit from one-another), debugging capabilities (ever wanted to skip a few lines while debugging), threading, live monitoring, error handling, and much more.

After a few years of passively complaining about these problems, I’ve decided to act, and see if I could somehow write my QTP tests in Visual Studio .Net. If I managed to pull that off, I would solve both the IDE problems (Visual Studio provides a wonderful – though not perfect – IDE, even in its free Express versions), as well as the deeper programming problems (.Net languages are fully fledged object-oriented language, with rich error handling, debugging, and other cool features).

In addition to these obvious benefits, additional perks await in Visual Studio. For example, hiding the automation code from snoopy clients (you could just compile the entire test into an executable form); built it .net extendibility, and more.

There are significant downsides as well (which may make the whole operation not worth your while) – adding another layer of code always causes problems and complexities; you cannot do this via QC; QTP’s automation agent randomly goes crazy and hangs the entire system, you’ll have to learn complex code techniques in order to take advantage of the inherent benifits in .Net; etc.

Having said that, I think it’s an idea worth exploring, even if only as an interesting adventure.

Building a bridge

It turns out that all you need in order to write QTP tests in VS is a bridge, allowing VS to “reach out” and touch GUI objects, though QTP. While building a fully functional bridge is indeed possible, and not even overwhelmingly complex (it took me a few intense days to build one), this article will only demonstrate a simpler “fixed” bridge as a proof of concept.

The main difference between our proof of concept to a fully functional bridge, is that the latter will allow us to write these sort of generic, almost QTP-native commands in Visual Studio:

SwfWindow("text:=AdvancedQTPDemo").SwfButton("swfname:=ClickMe").Click

while the proof of concept will only allow us to access one specific object “in the real world”.

However, as I’ve said, it’s only a matter of some hard work and some workarounds to develop the full bridge.

The QTP part of the bridge

Since all our tests will be written within Visual Studio, our QTP test will only contain our bridge. The QTP part of the bridge is just the object we would like to touch, stored within QTP’s environment variable. For this example, let’s say we have a browser opened to Google’s main search page, and we’d like to enter a query. Here’ the relevant code of the QTP test:

Environment.Value("Bridge") = Browser("index:=0").Page("index:=0").WebEdit("name:=q")

While 1=1

    Wait 0, 100

Wend

So basically, we’re storing a reference to the relevant object in the test’s environment variable, and putting the test into an endless loop. This will allow Visual Studio to access that object, and manipulate it as if we were touching it in QTP.

The Visual Studio part of the bridge

Now that we’ve prepped our QTP test, it’s time to bring it to life. We can simply open a new Windows Form project in Visual Studio, and within the Form-Load event, put the following code (here it’s in VB.Net, but it could just as well be in C#, J#, or any other language).

Const EngineTest As String = "C:\Bridge" 'The path to the QTP test

Dim pQTPApp as New QuickTest.Application 'This will require you to add reference to QTP automation model

Dim TestReady as Boolean = False

Dim Bridge as Object 'Will hold the actual bridge

pQTPApp.Open(EngineTest, False, False) 'Open the test

pQTPApp.Visible = True 'I like to see what's going on

pQTPApp.Test.Run(Nothing, False) 'Start the QTP test

While Not TestReady 'Wait for the test to become "alive"

    Try

        Bridge = pQTPApp.Test.Environment.Value("Bridge")

        TestReady = True

    Catch ex As Exception

        'Still not ready, loop over

    End Try

End While

So, what’s going on here? No need to worry if you’re unfamiliar with the syntax of VB.Net, the concept is pretty easy to grasp.

Simply put, Visual Studio launches QTP, opens our test, and then waits for it to be ready via a while loop.

What does “ready” means? Well, if we can get a hold of the object QTP injected into its environment variable, then the test is ready. If not, and error will be thrown, the Try-Catch block Would catch it, and the while would continue to another loop.

How can we actually use the bridge

Well, if all goes well, this means that the Bridge variable now holds a reference to a QTP WebEdit object. So we can go ahead and do something like this:

Bridge.Set "Some Value"

And surprise surprise – if the browser was opened to the right page, the webedit’s test would be set to “Some Value”.

So basically, we’ve proven that we can touch and manipulate GUI objects from Visual Studio through QTP.

Q.E.D.

From a proof of concept to a viable framework

While all this is fine as a proof of concept, the technique fails miserably as a general framework – it requires a separate variable slot for each GUI object, has no error handling for launching QTP (what if there’s an unsaved opened test?), has no methods for reaching child objects or expressing object hierarchies, and is generally inadequate for serious use.

As I’ve mentioned earlier, it is possible to build a more robust and sophisticated bridge that will provide cover all these issues and more. This was just meant as a simple, straightforward proof of concept.

On a personal note – I’ve been working with a fully fledged bridge for several weeks, and have been written some of my tests in Visual Studio, and the results are spectacular. If you have the necessary programming skills, I recommend the experience, even if only to open your mind to greater possibilities. Are you ready to step through the looking-glass?

Enjoy.