Following on from the last post, where we looked at the design of a simple helper automation framework, now we look at the files and code.
Grab the files here: https://github.com/MarkCTest/script-bucket > git-test-001.zip and click on ‘View Raw’ to download the .zip file.
In this working example, we navigate and log-in to GitHub then take and save screen shot. In the background a test log is being written out into a text file for test evidence, along with the screen shot.
There are four files in this example:
This file is used to control the flow of execution, provide the cored methods/subs and call in other needed files. This contains the following Sub (methods):
# Sub WaitForLoad
This Sub checks if IE is busy loading a webpage and if so, delays further execution for 500 milliseconds (0.5 seconds). This is far better than placing hard coded waits of explicit lengths in the hope they are sufficient for a process to finish, don’t do this!
# Sub Find
Used to read through the loaded webpage and read all elements of the page so we can use them later in our test cases.
# Sub Print
This writes out a line of text to the text-log.txt file object opened at the start of the script. Keeping a text log is a good way to trap errors and have test evidence that shows what steps were taken and how long they took.
# Sub Include
This is our magic method used to include all other files and tests needed for the framework. It is a technique I use often to build VBScript frameworks and mimics the Ruby Include method. In using this we can keep the length of the controller file much shorter and it is the key to having a modular framework.
You can make an argument that these subs should be in a separate file such as subs.vbs file, called in by the git-test-controller.vbs file. Feel free to refactor the framework with that edit.
First we print to our test log file that the test has started and then print out that each step has started. We navigate to GitHub, hit the log-in button and log-in. Log-in credentials are pulled in from a file with would be under the ‘data’ element of our framework design, namely the creds.vbs that has the username and password. See below.
Once logged in we open Paint, bring the browser (with GitHub) to the fore so it’s in focus then take a screen shot, saving that down for test evidence. That’s achieved by calling screen-shot.vbs described below.
A simple file that contains the credentials used to log-in to the system under test. You’ll see these are assigned to variables that are used in the git-test-001.vbs test script file. Replace the placeholder text with your own username and password.
Called in by LAF-Test-Controller.vbs, this takes a screen shot and saves it to the last save location Paint used. There is a big caveat with this file, as I mentioned in a YouTube video. Sometimes this doesn’t work. Have a look at the video here:
The single biggest thing to get right here is the name of the browser window. If it’s not correct it won’t be brought to the fore and your screen shot will be of whatever is the front/active window. Or the script will fail. Here’s the line and the title of the browser window.
WShShell.AppActivate "GitHub - Windows Internet Explorer"
You may find the title is different on your machine. For example "GitHub - Windows Internet Explorer provided by your IT team or company" is a common thing to see. Check it carefully.
The test log is written out as a .txt file in the same location as your script, you can change the location and file name in the git-test-controller.vbs file. All being well, it should look something like this:
The screen shot is saved in the last location that you saved something using Paint and is saved as testing.jpg, this is set in screen-shot.vbs and can be changed as needed.
That’s it, grab the code off GitHub, add your credentials to the creds.vbs and see how it works for you.
Check out the first post for the design of this framework
Enjoyed this post?
Say thanks by sharing, clicking an advert or checking out the links above!
Costs you nothing, means a lot.