Sunday, 10 April 2016

Tool Free VBScript Automation Framework Design

In a surprise turn I’ve been back to working with VBScript as my automation technology of choice on a recent engagement. Despite trying to move away from it, VBScript proves consistently easy to get going with and perfectly sufficient to achieve the automation or at least manumation activities that I need to carry out.

Not surprising, very often what’s needed is a little help to drive tests to a certain point, usually the same point via the same steps, so a lightweight VBScript automation framework with a few test cases is just the answer. Just the answer to addressing repetition, to addressing repetition, a lack of in-house tools, environments, budgets and so on. If you have a Windows system you have all the tools on board that you need, no messy installations and confusing set-up. Did I mention a great thing about VBScript is how accessible it is?

So what could a VBScript base automation framework look like? In this post we’ll look at the design, in the next we’ll look at the code.

Windows OS
As we’re running VBScript we’ll be running on a Windows box. I haven’t encountered any windows system that won’t run VBScript. If you know differently then be sure to let me know. For the diligent who’d like to test, add the following to a text file and save it as test.vbs, double-click and run it.

MsgBox "Well Well…" & VbCrLf & "I see an exciting future for the two of us.", vbOKOnly, "Result"

All being well you got a message box pop up. If so you’re good to go. If not, see above caveat.

Windows Script Host (WSH)
This is a host for scripts on the windows system, bet you didn’t guess that? It provides the ability to run batch like scripts on a Windows system, but with the capability to do much more. With WSH and VBScript there’s little on the system you can’t do something with. These in combination are a the key way to get automation done on a Windows system.

Core Elements
Naturally you can set-up your automation framework files in whatever way you prefer, but I suggest there are some basic coding / design rules to follow that just make good sense.
·         DRY – Don’t Repeat Yourself. Wherever it makes sense, anything that could be reused should be split out and put in a file or sub that can be called, not copy/pasted many times
·         Separation of Concerns – Split your framework files out into sections (files) that address separate areas of concern, we’ll see examples shortly

So what are the suggested core elements?

1) Controller File
We can think of a VBScript as a glorified batch script that gets executed all at once, let’s have a file that controls the flow of execution. This file set’s up some subroutines we’ll want to re-use (though maybe they should be split out actually…), it calls tests when needed and stops and starts testing.

2) Test Scripts
Each script we run should have its own file. These will be called by the Controller File. Following our two rules above, each script should do something unique. If there’s anything un-DRY then consider splitting this out into a utility script (see below) and calling it in your test script.

3) Data
Always get into the habit of splitting data out into separate files. Polluting your test script with reams of data just confuses things. Keep is simple smarty. The format of the data in our example here would be a simple .txt or .csv file for ease of use. However, using Excel is very common and we’ll look at that in a later post.

Utility Scripts
I also call these helper scripts. Essentially whenever you want some task carrying out that isn’t the test script proper, throw it in a utility script and call it from the test script. A good example is taking and saving a screen shot or writing out a text file.

Outputs
Not part of the set-up but part of the end result. These might include test logs and screen shots.

Here’s what the above would look like drawn up a diagram:



That’s the framework example, in the next post we’ll look at the code that foes behind this and in future posts we’ll look at a more complex version.


Mark.

0 comments: