Abstracting Test logic by inheriting VirtualClient

Ian1971

I just wanted to share with people a method I have found which enables me to abstract my test logic into a seperate class that can be inherited by my various browserClient classes.
I'm sure people are already doing this but it took me a short while to get working so if its going to save anyone else some time, here is what I did.
I created a new class which is called VirtualClient (if you don't call it this it doesn't work). this class inherits from Control.VirtualClient (just like normal browserClients do).
I can then create in this class all my various test functions, such as LogIn, LogOut, AddProduct etc.
I can then create my browserClient1 class, which inherits from my new VirtualClient class (instead of Control.VirtualClient as they normally do)
Now, within the browserClient1 class I can call all my test functions (as well as access all the normal VirtualClient objects).

This makes it much easier for me to work as I am not duplicating code in each browserClient class and it is much easier to read and maintain.

Cheers
Ian

Brian Donahue

Hi Ian,

That's the recommended approach. The only drawback is that your limited to one class full of functions that you can use from the load test script. Good enough, though!

Ian1971

I've extended this further into what I think now works quite well for me. The problems I kept running into was that the load test scripts were quite brittle (i.e. basically required extensive rewriting when a page changed). What I set out to do (and what I hope I've achieved) is a way of more simply updating my scripts.
Its a bit hard to explain briefly but what I have basically ended up with is a WebForm base class that is inherited and extended by specific types of web form in my application e.g. ProductWebForm. I then also have a tester base (which has to be called VirtualClient) which contains all my utility and debugging functions. This is inherited by my actual test classes e.g. ProductTester which contains the actual test logic and these classes call my various webform classes passing in themselves as VirtualClient objects.
The good thing now is that when for instance my Product page changes I only need to alter my ProductWebForm class rather than make changes in every class that was calling the product page.
I have also managed to get it working outside of the ANTS load shell, but still using the ANTS objects (by passing in a WebClient object) which means I can debug the whole thing in the visual studio IDE and step through the script code. As a nice side effect this also means I can use sourcesafe better with my test scripts. When it comes to do the actual load testing I just copy each class into the ANTS load project and I am away.

My wish list for ANTS would definately include making it more easily extendible and easier to debug. I have finally arrived at something I am happy with but I think if the object model had been created and documented with the thought that people could extend it then I would have saved a lot of time experimenting.
My ultimate tool would go further. It would have ASP.NET specific functionality allowing it to interact with the web application in a similar way to NUnitAsp but with load testing functionality. I think this would make writing scripts a lot easier and also make the scripts a lot simpler to change when controls change on the page.

Anyway, enough rambling
Cheers
Ian