distributedlife

Any serious service testing setup will build up a library of Vanilla C functions to assist in writing scripts for services as they come along. One the issues I have with Service Test parameters is that they persist for the life of the project execution. They’re created in the global scope and there they stay.

This means that when you write your helper functions you have to be careful what you call your parameters otherwise you will end up stomping on some variable that already exists ruining xmas for everyone involved.

What I find works is to use the following naming convention for my local parameters.

const char* GetYesterdaysDate (void)
{
        lr_save_datetime ("%Y-%m-%dT00:00:00", DATE_NOW - ONE_DAY, "__GetYesterdaysDate") ;

        return lr_eval_string ("{__GetYesterdaysDate}") ;
}

In this example we only have one local parameter and we name it after the function with double underscores. This helps indicate the parameter is an internal one and decreases the likely hood of someone using. Leading double underscore is a C standard for compiler implementation reserved keywords and a single underscore for library functions. With parameters there is less to worry about so I use double underscore to make it extra obvious it is a local scope parameter.

If you have more than one parameter in the local scope then you do the following:

void CheckRegistryValueNotFound (const char* const Server, const char* const SubKey, const char* const Property)
{
        lr_save_string (Server, "__CheckRegistryValueNotFound_Server") ;
        lr_save_string (SubKey, "__CheckRegistryValueNotFound_SubKey") ;
        lr_save_string (Property, "__CheckRegistryValueNotFound_Property") ;

        //more code
}

It may not look like much but putting some rigorous controls around the naming of parameters will save you grief.