Every so often, I am reminded exactly why using VBScript as the scripting language for QTP was a mildly bad idea.
Today, as you might have guessed, is one of those days.
See, I want to extend the Browser object in QTP. Oh, I can create user functions and register them with the browser (I do all of the time), but that isn't really the way I want this to work. I want to have a function off the browser that takes a name from a name-value pair in the query string and returns the value...like ASP.Net does.
Unfortunately, this is problematic in QTP. I can create a function to parse this information for me, sure. Easy as pie. Trouble is that it's dynamic; each time I need a value the whole thing has to run again. Now, I *could* use some other convoluted method to store this data, and I might do that. However, I don't like this design: it is slow, cumbersome, and inefficient. I would prefer a browser object that has this information loaded and ready to do as soon as it is instantiated. In another environment, I'd simply inherit the Browser and extend it.
I know that VBScript's dynamic, late-bound nature makes it impossible, but that's my point really. QTP does way too many things to use a scripting language of this sort rather than a more powerful true development environment. Not that QTP is horrible; it really isn't. It just isn't as powerful as some other options.
VBScript is a bit simpler (not really) than other languages, but the loss of power just doesn't justify it. In Rational Functional Tester, I have the full power of .Net or Java....real inheritance and everything! I can extend just about anything and do whatever I please. And heck, Java is free (I'd hate to pay licensing for .Net to generate tests).
Ah, well...back to my stone knives and furs, I guess. :-)
Print | posted on Friday, May 09, 2008 4:57 PM