This section provides recommended methodologies for testing a PATROL KM. You can also find a table that refers you to more information about recommended tools to use in PATROL KM development and testing. The following topics are discussed:

Recommended testing techniques

Code testing applies to all programming languages, and most of the general techniques apply just as well to PSL. Some recommended programming techniques are explained in this topic.

For testing code include the following:

• Unit testing - Writing code to test individual functions or elements of the code
• Inspections or walkthroughs - Manual, human analysis of source code
• Self-testing code - Adding code specifically for testing purposes
• Assertions - Specialized form of self-testing code that emphasizes condition testing
• Defensive coding style - Programming to gracefully handle unexpected conditions

Unit testing

The simplest form of regression testing is testing the individual units of a program. In PATROL KM development, the units that you could test could be the following types of PSL files:

• PSL files
• PSL libraries
• PSL user-defined functions

Testing PSL library functions using the PSL stand-alone interpreter

Some PSL library functions can be unit-tested by the PSL stand-alone interpreter. By applying the executable psl to a test file that exercises the library functions, you can unit test your product's functionality. However, the fact that the PSL interpreter does not deal with all PATROL Agent-specific built-in functions does limit the scope of this method.

Testing PSL library functions using a PATROL test KM

Another method is to write a separate PATROL testing KM to perform unit testing of functions in PSL libraries. This PATROL KM can use the PSL libraries and exercise them in the full PATROL Agent environment. Although it cannot mimic the results of functions that access the external environment (such as, files, processes, and so forth), it can mimic the internal PATROL Agent environment such as the symbol table, and more functionality can be tested.

Code inspections and walkthroughs

Manual inspection of code is an effective debugging tool. The following suggestions follow traditional software development inspection and walkthrough philosophy:

• Take time to re-read and evaluate your code.
• Perform group inspections of the code.
• Follow formalized walkthrough methodology in which the developer presents and explains the code by stepping through its execution.

Self-testing code

The general idea of self-testing code is to add code that performs internal checks for anomalous conditions. For example, a PSL user-defined function could validate its own arguments. Many other forms of self-testing code are possible. For example, your PSL code could contain sophisticated internal unit tests, provided they are hidden by a special test that cannot occur in production:

if (get("doInternalSelfTests")) {
ret = test_my_function(1);
if (ret !=0) {
  print("Internal unit test failed\n");}
}

The performance overhead to the production code is minimal. Unfortunately, there is no pre-processor in PSL with which to compile these tests out. You can, of course, manually comment this code out prior to completion.

Assertions

Assertions are a specialized form of self-testing code. There is no direct support for assertions in the PSL code or in any standard PSL libraries. However, it is not difficult to add a user-defined PSL function called assert() and have it behave as assertions do. For example:

function assert(condition,message)
{
if(!condition){
print("ASSERT FAILED:",message,"n");
}
}
}
#use the assert functionality
assert(x>0,"x out of bounds");

Unfortunately, there is no way in PSL to do some of the things commonly handled by C language assertions, such as showing the script line number and file name. The origin of the assertion can automatically be detected by clever use of PSL and some knowledge of the different contexts of execution in the symbol table.

Defensive coding style

PATROL KM quality depends on the coding style of the developer. In particular, does the code handle the unusual cases involving external failures, or even internal bugs in the code? 

Return code checking is the simplest of defensive coding techniques. The code should handle all possible situations even if they are unexpected. Return code checking is necessary for external functions that could fail due to something beyond the control of the program, such as a channel failure, a dying process, or a missing or corrupt file. Some of the PSL built-in functions that should have return codes checked include the following:

• system(), execute(), popen()
• read(), write(), fopen(), fseek(), ftell()
• process(), proc_exists()
• file(), cat()

Techniques to detect failure conditions include:

• Checking the actual return code in the process
• Checking the errno return code in PSL functions in which it is available
• Checking the exit_status PSL variable in the PSL system() or execute() functions to examine the child process's execution termination state.

An even more defensive coding style is to check all PSL return codes. This includes not only other built-in functions but also the user-defined PSL function results. This safety net can find not only exceptional conditions but also internal hidden coding bugs. However, since this approach is resource intensive, a balance needs to be set according to external project influences.

About KM development tools

The following table lists PATROL KM development testing and tuning tools with a brief description of each along with where you may find more information about the tool.

About debugging