Internal interfaces

This section separates the CCT into components and characterizes the interfaces between them.

CCT Library

The Card Conformance Tool Library (CCTL) exposes the functionality exercised by both the GUI and the 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 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 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 will result in a TestResult object that can be serialized back to the database. This will include a boolean result and a human-readable message that may provide additional information about the test. The test runner (GUI or command line) will store this in the database with a reference back to the TestCase instance that produced it using a utility function exposed in the CCTL. Groups of test results will be stored to correspond to a test run.

Report generation

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

Log configuration

It is anticipated that most test cases will log information at different levels during setup, execution and teardown. The CCTL will provide an interface for either the GUI or the command line runner 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 more easily differ between the GUI and the command line front-ends.

Subcomponents

While the CCTL will provide the interfaces used by the two front-ends, most of the implementation of these interfaces will be delegated to subcomponents. This will serve to ease implementation of a more diverse set of test cases as well as to allow reuse of the smart card interface in other test tools.

Test Logging Library

The test logging library will set up categories and log levels as well as provide logging functions for data types commonly logged by test cases in the CCTL. It will augment the slf4j rather than hide its interface; once the test logging library is used to set up appropriate facilities test cases may use slf4j interfaces directly for logging where that makes sense.

Test Component Library

The test component library will encompass two functions that may later appropriately be split into separate libraries but currently are tightly enough coupled that it makes more sense to keep them in the same library:

• 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 will expose an interface that is very similar to that documented in SP800-73, although it will not be a complete implementation of that specification and will make allowances for more idiomatic java practices where those are beneficial.

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