I’m thinking of writing a WinRunner Coding Standards document (as if there weren’t enough of them out there already), but with more of a focus on why things should be done a certain way rather than just dictating how code should be written.
Here is a sample section. Is anyone interested in reading a document like this?
No magic numbers
Here’s a quick quiz for you. What does the numeric argument to the tl_step function below set the test step status to?
tl_step(“Check that transaction completed successfully.”, 0, “Transaction did not complete successfully.”);
If you answered “fail”, you probably figured it out from reading the other arguments to the function – and you would be wrong. If you answered “pass”, you probably need to spend less time reading the WinRunner manual and more time actually testing. The tl_step function interprets a 0 value as a pass, and any other number as a fail.
Accidentally using a pass value instead of a fail value is quite a nasty bug. If a test script fails when it should not, someone will investigate and find the mistake in the script but if it passes when it should not, the first you will hear of it is when a user discovers a defect in Production. No one reads the comments in the WinRunner Test Results unless something fails.
Here’s another quiz. What does the following line of code do?
Do you give up? Obviously WinRunner will continuously loop until the return value of the get_mouse_cursor function is no longer equal to 65557, but what does this magic number 65557 really mean? Whoever has to read your test scripts when you’re gone won’t have to spend time pondering this sort of question if you use a descriptive constant name instead of a unintelligible value.
A good rule to follow is that no-one who has to read your scripts should have to know what a number means, unless it is obvious from the way it is used (like a time delay, or an index). This applies to the standard WinRunner functions and any that you create yourself. Some of the example documentation even uses magic numbers instead of the WinRunner constants; hopefully this will be fixed in future versions of the tool.
The wr_gen compiled module in the lib directory of your WinRunner installation defines all the constant values used by WinRunner. Some common ones are…
- TRUE, FALSE
- PASS, FAIL
- ON, OFF, TOGGLE
- E_OK, E_GENERAL_ERROR, E_NOT_FOUND etc.
- FO_MODE_READ, FO_MODE_WRITE, FO_MODE_APPEND
Some of these constants are inserted for you automatically while recording or using the function generator, but you must insert many of them manually. Future maintenance and readability should take precedence over the minor inconvenience of replacing a small number of values by hand.
Comments are closed.
I’m glad you posted this. Magic numbers are one of my pet-peeves. 😉
I am interested in a doc like this, did you ever create one?
Great blog! I would definitely be interested in hearing your thoughts on this subject.
WinRunner has defined constants for all (or nearly all) the magic codes in the application. I encourage scripters to use these names instead of the numbers. It makes code easier to read.
My reporting framework also looks up the error codes and reports the definitions instead of just the numbers. That makes results analysis much easier.