Mr. Cluey : Special Topics : Using Compiler Constants

Using Compiler Constants

What's a compiler constant?

A compiler constant is a special kind of variable in QA Partner. It's value is not specified in any script. Instead, you declare the constant and set the value in the Runtime Options dialog.

The primary value of compiler constants is that you can change them without making any changes to your code. This gives you a means to change the behavior of a script without actually changing the script itself.

Here is an elementary example

main()
{
	print ( MY_STRING ) ;
}

If we set MY_STRING = "foo", the script will print foo to the results file. If we want the script to print "bar" instead, we don't need to change the script, just set MY_STRING = "bar", and rerun the script.

What fun.

How should compiler constants be used?

The key idea is that you want to use these constants to change the behavior of the script. In other words, you are trying to change how the script works. For example, you might use the compiler constant to...

• specify whether you want debugging messages reported in the event log.
• change which database the application uses
• change which version of the application is used
• specify which error reporting mechanism to use
• change the environment used to run the test
• specify information about the person running the script

There are a lot of possibilities.

Implementation

Writing scripts that use compiler constants is straightforward, as the example above showed. Just write the script using the constant (as opposed to using the literal) as in the example above, and define the constant in the Runtime Options dialog. Hey presto! You run the script, and magically enough, it just works.

Until somebody else tries to run it - at which point it will fail to compile.

The problem is that compiler constants are local to each instance of Partner. Unless you tell everybody to add your new constant to their environment, they won't be able to run your scripts. There are steps that you can take to make it easier for them, but truth be told, we've not improved much beyond making everybody change the scripts by hand.

But it is possible to add compiler constants to a script invisibly, if you are willing to put in some extra effort.

The key idea is NOT to use the constant directly - not everybody will have defined it. Instead, you should create a constant inside your script, and initialize the script constant from the compiler constant. For example

theConstant = MY_CONSTANT ;

Of course, this still doesn't compile - we have the same problem that we did before; the variable name isn't recognized. That can be fixed with the reference operator

theConstant = @("MY_CONSTANT") ;

Now the code compiles, but you will get a runtime error when this line is executed. This is better than before, but not much. What we really want is to use the compiler constant, but to have a default value in reserve. Unfortunately, that calls for some logic, and we can't really put logic into an assignment.

But we can put logic into functions, and use functions for assignment

Default_Constant = /* put the default value here */ ;
theConstant = LoadConstant () ;

anytype LoadConstant ()
{
	anytype tempConstant = Default_Constant ; //
	do
	{
		tempConstant = @("MY_CONSTANT") ;
	}
	except
	{
		; // no code needed here, tempConstant has already been assigned a default value
	}

	return ( tempConstant ) ;
}

LoadConstant() will get called when it is time to initialize theConstant, if MY_CONSTANT has been set, that value will be used but if it hasn't, no worries! your carefully selected Default_Constant will kick in. Your scripts, and those of your other developers, use theConstant without having to worry about where it came from.

Load constant itself is pretty generic, so you might think about creating a function to encapsulate it. Not a bad idea, but there is one trap to watch out for - as of Silk 1.1, you couldn't specify a window as a compiler constant - you'll have to play games with strings and the reference operator.

Compiler constants and the command line

Compiler constants are stored in the options file. If you are dealing with a number of different test machines, each of which has a different set of compiler constants to use, you create and load a different opt file for each machine, and define the correct constants for each.

With only one copy of partner, it is harder - Partner does have a command line switch which allows you to specify which opt file to use; unfortunately, that functionality is implemented only on OS/2. There are two alternatives available - prior to launching Partner from the command line, you can either

• overwrite the current opt file with one that has the constants that you want
• change the Partner configuration file (partner.ini for those of you in windows) so that the OptionsSet variable points to the appropriate file.