If your custom code uses the IKLog interface to report test results, you can inspect the results in the test's execution history. If you log custom verification point verdicts, these are reflected in the overall schedule verdict.
Here are some examples of what you can do with custom code:
In your custom code, you use the IKLog interface to report the results of your tests. This interface is part of the com.ibm.rational.test.lt.logging package. IKLog methods are of two types:
When you add custom code to a test, you see the following in the test editor:
If you click Generate Code, a template custom code class is created in the project's src folder. Before generating the template class, you can provide a different package name (recommended, because otherwise your custom code will reside in the same package, test, as the generated test code) and a class name descriptive of the function performed by your code. Or you can reuse existing custom code by typing its package and class name, and then open the class by clicking View Code. For example, if you enter test.custom.VerifyCustID as the package and class name, the code shown below is generated in src/test/custom/VerifyCustID.java and opens in the Java editor.
package test.custom; import com.ibm.rational.test.lt.kernel.logging.IKLog; /** * @author unknown */ public class VerifyCustID implements com.ibm.rational.test.lt.kernel.custom.ICustomCode { /** * Instances of this will be created using the no-arg constructor. */ public VerifyCustID() { } /** * @see com.ibm.rational.test.lt.kernel.custom.ICustomCode#exec(IKLog, java.lang.String[]) */ public String exec(IKLog log, String[] args) { return null; } }
By default, the Test Navigator view opens in the Test perspective. Normally this is the best view for navigating tests because it filters out many files that are not relevant to testers, including contents of the src folder. When writing custom code, you might want to open the standard Navigator or a Java navigation view, as doing so allows you to navigate your code directly. (You can open custom code from the calling test by selecting it and clicking the View button.)
Your custom logic and logging statements go in the exec block at the bottom. If you type log. inside this block and click Ctrl-Space, the Java editor lists the IKLog methods and displays their Javadoc. To manipulate input values from the calling test, operate on the args array, which contains any arguments that you designated when you added the code to the test: see Adding custom code, steps 4-6. The return statement optionally returns a value to the calling test.
As illustrated in Logging a simple message , you can write a message to the execution history with reportMessage directly. The other methods require access to classes that create event objects. To gain access to these classes, add one or more of these import statements:
import org.eclipse.hyades.test.common.event.ExecutionEvent import org.eclipse.hyades.test.common.event.MessageEvent import org.eclipse.hyades.test.common.event.VerdictEvent
If you add custom code containing the import statements above to a test that is located in a project in which no test has ever been run, you might get import errors. However, if at least one test in the project has been run previously, you will not get the errors. This is because running a test adds known libraries required for execution, including the classes named in the import statements, to the project build path.
The VerdictEvent class is the most relevant for custom code, because verdicts logged to the execution history with the reportVerificationPoint method are reflected in the test's pass/fail verdict. A schedule's verdict is pass only if all of its tests pass, or if no verdicts are reported by any test. The example Logging a verdict event illustrates how to create and log a verdict event.
Schedule editor setting | IKLog literal |
---|---|
All | HISTORY_ALL |
None | HISTORY_NONE |
Schedule | HISTORY_SCHEDULE |
Page | HISTORY_PAGES |
Request | HISTORY_REQUESTS |
Based on the schedule editor settings, results are filtered out of the execution history. Thus, it is possible that a result logged by your custom code will not appear in the execution history. Use getHistoryLevel to get the history level setting and wouldReportHistory to conditionally report a result based on the setting. (If you run an individual test directly, the setting is HISTORY_ALL.)
Parent topic: Extending tests with custom Java code