public interface TestRecorder
TestSet,
Author: Keith Swenson| Modifier and Type | Method and Description |
|---|---|
java.lang.String[] |
getCommandLineArgs()
The command line arguments to the main routine are stored in the
TestRecorder.
|
java.lang.String |
getProperty(java.lang.String name,
java.lang.String defaultVal)
A configuration file 'test.conf' is read automatically and is represented
in the TestRecorder as a Properties object.
|
java.util.Properties |
getProps()
Tests generally should not use this method but rather should use the
convenient routines getProperty and getRequiredProperty,
|
java.lang.String |
getRequiredProperty(java.lang.String name)
A configuration file 'test.conf' is read automatically and is represented
in the TestRecorder as a Properties object.
|
java.lang.String |
getTestDir()
getTestDir returns the path to the folder that contains all the test
files.
|
boolean |
isVerbose()
Returns the value of the 'verbose' configuration parameter.
|
void |
log(java.lang.String s)
Writes the specified string to the log file, only when verbose == true.
|
void |
markFailed(java.lang.String id,
java.lang.String details)
When a simple test fails, for example a simple calculation performed, and
the result does not matched the expected result, then this is called to
indicate that the test failed.
|
void |
markFatalError(java.lang.Exception e)
A "fatal error" is an error that is so bad that subsequent tests were
skipped.
|
void |
markPassed(java.lang.String id)
When a simple test passes, for example a simple calculation performed,
and the result matched the expected result, then this is called to
indicate that the test has succeeded.
|
void |
setCommandLineArgs(java.lang.String[] args)
The TestDriver may call this method if it needs to add/modify the command
line arguments.
|
void |
setProps(java.util.Properties props)
setProps should not be used except in extreme situations where particular
properties need to be added or modified for a particular test.
|
void |
testInt(java.lang.String id,
int value,
int expected) |
void markPassed(java.lang.String id)
This will record the fact the that test succeeded and report it in the final results. The id is a simple name or description that can be used to uniquely identify this test. It might consist of the test number in a particular test set.
When verbose=false (normal situations) this will not produce any output to the log. The logic is that normally we will have hundreds of tests, and they all pass so we don't really need to know about those.
When verbose=true, it will record this pass to the log, which allows you to get a listing of all the tests that were run if you wish.
void markFailed(java.lang.String id,
java.lang.String details)
A log entry is printed to record the fact with the details regarless of whether verbose==true or verbose==false. The rationale is that you always want to know about failures. Not only is the id and details written out, but also a line that include the parameters that were passed to the test, as well as any log messages that were saved up since the last result message.
id - follows the same rules as above (and it goes without
saying that the same id should be used when indicating
success as when indicating failure for a particular test.)details - is additional information explaining what was expected and
what was wrong about it. For example to explain what was
being done, what was unique about this test case, which
might give a clue to why the program failed.void markFatalError(java.lang.Exception e)
Recording a fatal error means tests has been skipped in this run, and the resulting statistics are meaningless. We don't have a complete record of all the tests that might have failed. The presence of a single fatal test should tell you that something is terribly broken in the tests, and the results are not valid.
Normally, a test case will indicate a fatal error by throwing an exception. The Test Framework will catch the exception, and use this method to record that a test failed to the extent that further testing had to be skipped. Throw a meaningful exception instead of calling this routine.
void log(java.lang.String s)
Do not use the log method to write out whether a test passes or fails! It is remarkable how many time programmers write tests that require a person to read the log a determine whether the test succeeded or not. In normal testing situation, nobody reads the logs! In the case of automated builds, the automated run of a test produces a log, but if no error is indicated using markFailure, then nobody ever looks at the log files. So use it only for debug information while developing the test.
Note: there is a special capability to reduce clutter and still get meaningful results. When the log method is called, and verbose==false the line is not written to output, but is is saved up in a collection. If the next test result is "pass" then those lines are thrown away. But if the next result is "fail" then those saved up log items are output just before the failure message. So if you are outputting information using log statements before reporting the results of a test, those statements will be seen even with verbose==false if the test fails.
boolean isVerbose()
java.lang.String getProperty(java.lang.String name,
java.lang.String defaultVal)
java.lang.String getRequiredProperty(java.lang.String name)
throws java.lang.Exception
java.lang.Exceptionjava.lang.String getTestDir()
void testInt(java.lang.String id,
int value,
int expected)
java.util.Properties getProps()
void setProps(java.util.Properties props)
java.lang.String[] getCommandLineArgs()
void setCommandLineArgs(java.lang.String[] args)