Internal interfaces

This section separates the Card Conformance Tool (CCT) into components and characterizes the interfaces between them.

CCT Library

The Card Conformance Tool Library (CCTL) exposes the functionality exercised by both the graphical user interface (GUI) and the command line interface (CLI), including the following interfaces:

• Test Case Manipulation - instantiate and configure TestCase objects
• Test Case Execution - set up, execute, and tear down one or a series of TestCase objects, returning a TestResult object
• Test Case Serialization - write a TestCase object to a Card Conformance Test Set (CCTS) document
• Test Result Serialization - write a TestResult object to a CCTS document
• Report Generation

TestCase interface

interface TestCase {
	Map<K,V> getDefaultParameters();
	TestResult run(Map<K,V> parameters);
	void setup(Map<K,V> parameters);
	void tearDown(Map<K,V> parameters);
	String getIdentifier();
	String getDescription();
	boolean getExpectedResult();
}

Specific test case classes implement this interface. To manipulate parameters, the GUI instantiates the test case class, calls getDefaultParameters(), and shows a user interface (UI) to edit any returned configurable values.

To serialize a test case, the GUI supplies the edited map of parameters back to the CCTL along with the class name, and the CCTL writes this to the SQLite database.

To execute a test case, either the GUI or the command line test runner uses a utility function within the CCTL to deserialize the test case and instantiate it. Then it calls setup(), run() and teardown() in that order before serializing the returned TestResult to the database.

TestResult interface

interface TestResult {
	boolean getResult();
	String getMessage();
}

Test execution results in a TestResult object that you can serialize back to the database. This includes a Boolean result and a human-readable message that may provide additional information about the test. The test runner (GUI or CLI) stores this in the database with a reference back to the TestCase instance that produced it using a utility function exposed in the CCTL. The tool stores groups of test results that correspond to a test run.

Report generation

The CCTL exposes a utility function that can generate an HTML report for one or more test runs based on results stored by the runner.

Log configuration

Most test cases log information at different levels during setup, execution, and teardown. The CCTL provides an interface for either the GUI or CommandLineRunner to configure the verbosity and disposition of these log events using an slf4j configuration file. By using slf4j rather than using log4j directly, specific details of log disposition can be more easily distinguished between the GUI and the CLI.

Subcomponents

While the CCTL provides the interfaces used by the two front-ends, most of the implementation of these interfaces is delegated to subcomponents. This serves to ease implementation of a more diverse set of test cases and allows reuse of the smart card interface in other test tools.

Test Logging Library

The test logging library sets up categories and log levels and provides logging functions for data types commonly logged by test cases in the CCTL. The test logging library augments the slf4j instead of hiding its interface. Once you use the test logging library to set up appropriate facilities, test cases may use slf4j interfaces directly for logging where appropriate.

Test Component Library

The test component library encompasses two functions:

• Concrete test case implementations
• Test "step" implementations

A test case consists of one or more steps. While each test case is unique, many steps are reused across test cases.

Smartcard Interface Library

The smartcard interface library exposes an interface that is very similar to that documented in SP800-73, although it is not a complete implementation of that specification. The smartcard interface library makes allowances for more idiomatic java practices where appropriate.

Implementation of the smartcard interface uses javax.smartcardio where feasible, only resorting to platform-specific native libraries if absolutely necessary.