Running Unit Tests in Batch Mode

You can run the JadeUnitTestBatch application:

From version 2016.0.02 (Service Pack 1) and higher, as a standard client or a thin client from the JADE executable (jade.exe) command line, see "Running a JADE Client Application using jade.exe", in Chapter 1 of the JADE Runtime Application Guide.

The JadeUnitTestBatch application requires the elements within the startAppParameters and endAppParameters arguments of the jade.exe command line.

To run unit tests in batch mode as a non‑GUI client application using jade.exe, specify the following arguments in the command line.
```
jade path=database‑path
     schema=RootSchema
     ini=jade‑initialization‑file
     app=JadeUnitTestBatch
     startAppParameters
     control‑file‑name
     test‑name
     [codeCoverage=true|false]
     [profile=true|false]
     [log‑file‑name]
     endAppParameters
```
The following example specifies the JADE executable (jade.exe) command line for the non‑GUI JadeUnitTestBatch presentation client application.
```
jade path=c:\jade\system schema=TestUnitTestSchema ini=c:\jade\system\jade.ini app=JadeUnitTestBatch appServer=MyAppServer appServerPort=1234 startAppParameters c:\jade\unittest.xml DailyTests codecoverage=true profile=true c:\jade\logs\unittest.log endAppParameters
```
For details about running the JadeUnitTestGuiNoForms application from jade.exe, see "Running Batch Mode Unit Tests that Require GUI Components", later in this chapter.
Using the jadclient non-GUI client application to automate the batch running of unit tests, passing command line arguments after the startAppParameters argument to specify your testing and logging requirements. For details about the jadclient non-GUI client application, see "Running a Non-GUI Client Application using jadclient", in Chapter 1 of the JADE Runtime Application Guide.

To run unit tests in batch mode as a non-GUI application using jadclient, specify the following arguments in the command line.
```
jadclient path=database-path
          ini=jade‑initialization‑file
          app=JadeUnitTestBatch
          schema=schema‑name
          startAppParameters
          control-file-name
          test-name
          [profile=true|false]
          [log-file-name]
          [codeCoverage=true|false]
```
The following is an example of the command line that runs a non-GUI client application to run the DailyTests unit test, which is defined in the c:\jade\unittest.xml XML file.
```
jadclient path=c:\jade\system ini=c:\jade\jade.ini server=multiUser schema=RootSchema app=JadeUnitTestBatch startAppParameters c:\jade\unittest.xml DailyTests c:\jade\logs\unittest.log
```

The arguments following the startAppParameters argument are listed in the following table.

Argument	Description
control-file-name	Name of the XML control file that defines groups of tests that can be run.
test-name	Name of a group of unit tests specified in the control file.
codeCoverage	Specifies whether code coverage is enabled or disabled in the JadeUnitTestBatch application. This argument is optional, as you can also specify whether to enable code coverage in the control file. (Applies from version 2016.0.01 and higher.)
profile	Specifies whether unit test profiling is enabled or disabled in the JadeUnitTestBatch application. This argument is optional, as you can also specify whether to enable unit test profiling in the control file.
log-file-name	Name of a log file used for error and test output. This argument is optional, as you can also specify the output destination in the control file.

The control file has the following format.

<unitTest>
    <reporter schema="schema name" class="class name" logFile="file name"/>
    <schema name="test schema name"/>
    <options deltaName="delta name" logCallStack="true" codeCoverage="true"
         profile="true"/>
    <tests>
        <test name="test name">
        ...
        </test>
    </tests>
</unitTest>

The file can also have the following standard XML declaration header.

<?xml version="1.0" encoding="utf-8"?>

The <reporter> XML element is optional, and is used to specify where the unit test output goes. If a schema and class name are specified, they must correspond to a class that implements the JadeTestListenerIF interface. A transient instance of this class is created and the unit test results are passed to the respective interface methods as the tests are run.

If a logFile is specified and is valid, the unit test results are written to this file. If both the schema and class name are specified, they take precedence and the logFile value is ignored. If neither the schema nor class name are specified or are invalid, error output and test result output are written to the log file specified as the third argument in the jadclient command. If the log file is not specified or is invalid, output is written to a file named JadeUnitTest.log in the directory specified by the DefaultLogDirectory parameter in the [JadeMonitorBackground] section of the JADE initialization file.

The <schema> XML element is optional, and is used to specify the default schema in which the unit test classes are defined.

From version 2016.0.02 (Service Pack 1) and higher, the <options> XML element is optional. You can use it to specify multiple options; for example, <options deltaName="delta name" logCallStack="true" codeCoverage="true"/>.

The deltaName option indicates that unit tests and methods checked out to the specified delta should be run.
From version 2016.0.03 (Service Pack 2), the logCallStack option indicates whether the call stack is logged when an assert or exception occurs. By default, the call stack is logged; that is, logCallStack="true".
The codeCoverage and profile options indicate whether the unit tests have code coverage and profiling, respectively. By default, code coverage and profiling are not enabled; that is, codeCoverage="false" and profiling="false", respectively. (You can also specify on the command line that code coverage and profiling are enabled.)

The <tests> XML element, which must be present, contains one or more <test> XML elements. Each <test> XML element is specified, identifying at least one unit test class to be run.

Tests can also include the contents of other tests, by using the <includeTest> element, as shown in the following example.

<includeTest name="test name"/>

This copies the contents of the test specified by the name attribute into the current test.

The following example shows the structure of a typical <test> XML element.

<unitTest>
    <options deltaName="dawn" logCallStack="true"/>
    <tests>
        <test name="DailyTests">
        <schema name="TestUnitTestSchema"/>
        <class name="UnitTests" includeSubclasses="true"/>
        <class name="WithdrawalTests">
            <method name="overdrawn"/>
            <method name="exceedsLimit"/>
        </class>
        </test>
    </tests>
</unitTest>

The <schema> XML element, which must have a name attribute corresponding to a valid schema, specifies the unit tests to be run for classes in the schema. The <schema> XML element has the optional attributes shown in the following examples.

<schema name="DemoUnitTestSchema" runAllTests="true"/>

<schema name="DemoUnitTestSchema" runAllTests="true" includeSubschemas="true"/>

The default value of the runAllTests attribute is false. If the runAllTests attribute value is true, all unit test methods of all subclasses of the JadeTestCase class in this schema are run as part of the test. In this case, any <class> XML elements in the test are ignored. The default value of the includeSubschemas attribute is false. If the includeSubschemas attribute value is true, all unit test methods of all subclasses of the JadeTestCase class in this schema and its subschemas are run as part of the test.

The <class> XML element, which must have a name attribute corresponding to a valid subclass of the JadeTestCase class, specifies the unit tests to be run for the class. The variants of this class element are as follows.

Class name only.
```
<class name="test class1 name"/>
```
In this case, all unit test methods of the class are run as part of the test.
Class name with <method> children.
```
<class name="test class2 name>
    <method name="test method1 name"/>
    <method name="test method2 name"/>
</class>
```
Each <method> XML element must have a name attribute corresponding to a valid unit test method within the class. When <method> child elements are present, only the specified methods are run in the test.
Class name with a name attribute and an includeSubclasses attribute.
```
<class name="test class3 name" includeSubclasses="true"/>
```
The default value of the includeSubclasses option is false. If the value is true, all unit test methods of the class and all of its subclasses are run as part of the test. If the option includeClasses attribute is set to true, any <method> children for the <class> element are ignored.

The jadclient non-GUI client application returns zero (0) if there were no errors; otherwise it returns an exception code. For example, if one or more tests fail, the exit code is 1467, in which case you can check the JadeUnitTest.log file for details of the failed test or test. Error 1466 is an indication that an incorrect argument was specified; for example, an invalid schema name or test name, and so on.