During some recent work with a client, I had the task of pulling up about 100 automated regression tests for a critical business application. These scripts were frequently executed, and took hours to complete. They had also been in service for years and seen many updates, but we knew they worked… or did they?
Building the Project
The first thing I did was create a new project in Test Design Studio to include these various tests. In addition to the tests, I added all the relevant function libraries and object repositories. Each of these assets were stored in Quality Center/ALM, and Test Design Studio handled them perfectly. That’s when the fun begin.
Hello “Option Explicit”
Test Design Studio features a code analysis feature that helps you focus on improving the quality of your code. Now that my project was established, the code analysis was lighting up all the areas I needed to address. If there is one practice I have always preached for writing VBScript-based code, it is this… turn on “Option Explicit”. When set, this requires the VBScript run-time engine to throw an error if you attempt to use an undeclared variable. Anyone who has ever mistyped the name of a variable and tried to debug why their script failed knows exactly what I’m talking about (hint: VBScript just uses the mistyped name as a new variable with an empty value). When over 50 of the tests were displayed in my Error List as not having Option Explicit set (which is one of the code analysis rules you can turn on), I knew it was my first order of business.
Updating the Files
Remember, all of these tests are in Quality Center/ALM and are scattered between folders. What would normally be a daunting task of searching out the noncompliant tests, opening in QuickTest (switching to Expert View), and saving back was made remarkably fast by Test Design Studio. The process was simple…
- Double-click the error in the Error List that indicated the lack of Option Explicit. It did the heavy lifting of finding the right file.
- The file was opened directly in Test Design Studio with the code readily available.
- A pasted in my line for “Option Explicit”.
- Saved and closed the editor.
- On to the next error; repeat.
What a relief! I had those 50-or-so tests updated quickly.
What About Those Undimmed Variables?
Now comes the tricky part. Turning on Option Explicit may sound like a simple task, but the consequences can be devastating for an existing script. If I run the tests “as-is”, they will throw an error and halt execution any time an undeclared variable is used. These tests are critical, and silly failures like this cannot be allowed. Executing, fixing, executing, and fixing would take hours for each test. Many of these scripts were 1000’s of lines long and could take over 30 minutes to complete. Variable declaration was never required, so the assumption was that many of the variables in use had never been declared. That’s when I saw the new Error List from Test Design Studio. It contained over 1,200 errors, most related to the use of an undeclared variable. Thankfully, that’s another code analysis rule you can turn on in Test Design Studio!
Without code analysis, I never would have dared to scour all those lines of code looking for every possible variable reference and making sure it was declared. When adding all those declarations, it’s also easy to accidentally declare a variable in one section of code that was already declared somewhere else. That, too, can cause a run-time error. You guessed it… Test Design Studio has a rule for that too!
My process was simple… I would find one of the errors in the list and open that test. I’d then filter the error list to only show me the errors for the currently opened file. That let me know exactly how much work was before me. When I’d find the usage of an undeclared variable, I’d do a quick “Find in File” to see all the places in the test where the variable was used. Once the file was clean, I’d save/close, restore my error list to the unfiltered view, then pick the next error from another file.
Most of the time, the variables were legitimate and needed to be declared. Sometimes I found that variables were assigned values but never actually used in the test! That’s confusing to new authors trying to understand a test, so I got rid of those (they were left over from previous versions of the test that were later modified). The worst is when I found variables that were used but never assigned! The author of the test clearly expected a value to be in the variable, but it was always going to be blank. That could lead to the test not validating the functionality it was designed to test. Was this test even valid?
How Did It Turn Out?
After spending a couple hours going over all the tests, adding Option Explicit, and fixing all those variable references, I found several logic errors in the script that never would have happened if Option Explicit had been turned on to begin with (confirming my theory that you should always use Option Explicit). When the tests were executed, not a single run-time error was encountered from all those changes.
Tens of thousands of lines of code, and I didn’t miss a single variable… THANK YOU TEST DESIGN STUDIO!
Use Test Design Studio For Your Own Projects
You can find out more about how the Code Quality features in Test Design Studio on this special feature page. Of course, you can also download a fully functioning trial version of the software and try it out for yourself.