Every time someone uploads a script to the (web-based version of the) VuGen Validator, I get emailed a copy of the validation report for their script. Needless to say, I see a lot of really bad scripts…and hopefully the script developers learn something from the failing grade their scripts are given by the Validator.
One thing that worries me is that lately I have seen a lot of BPM scripts containing the following code…
// script body removed from example.
It seems to be spreading virally between script developers as they cut-and-paste a piece of code they clearly don’t understand at the beginning of all their scripts.
Just in case you are new to all of this, let me give you some background.
- BPM scripts are very similar to LoadRunner scripts, in that they are also developed with VuGen.
- But BPM scripts are used for monitoring an application, rather than load testing.
- Every 15 minutes (or whatever), the BPM script will be invoked on a BPM host. A new mmdrv.exe process is created, and the script runs in this. After the script has run, the mmdrv.exe process terminates. No state is retained between invocations of mmdrv.exe.
- BPM scripts typically run for a single iteration each time they are invoked, and will never have complex run logic (percentage weightings, etc.).
So what does the above code do?
- web_cache_cleanup(): Deletes the client-side cache for the vuser. But, as this function call appears at the beginning of the script and they will only do a single iteration, the vuser will always have an empty cache, so this function does nothing.
- web_cleanup_cookies(): Deletes stored cookies for vuser. But for the same reasons as web_cache_cleanup(), this function does nothing.
- web_set_sockets_option(“CLOSE_KEEPALIVE_CONNECTIONS”, “1”): This function causes the replay engine to close all open TCP connections. But at the start of the script, before any web requests have been made there are no open connections.
- Note complete lack of comments, explaining why they have added the code.
This kind of cut-and-paste programming behaviour worries me because:
- The developer clearly does not understand the code they are using.
- The developer has never bothered to read the documentation for the functions or think about how their tool works.
- The developer has the attitude of “if the code runs, then it must be working”, which is a really bad practice when the code is designed to measure something. Code that runs successfully is not necessarily making an accurate measurement.
The script developer is engaged in “voodoo script development” (similar to Cargo Cult Testing), where they copy code from other scripts, or from the Internet but they don’t understand how it works (and certainly can’t explain the code to others). Rather than establishing a clear relationship between cause and effect, they try things at random until their code appears to work, and then they consider it finished. These people leave messes for other people to clean up, and spread confusion wherever they go.
If you read this, and think “hey, that’s me”, please find another job that is more suited to your technical skills…perhaps basket-weaving.