Framework Testing


The Real Time Java Framework was first developed in a desktop environment and then ported to an embedded processor. Testing is performed at several levels and in several stages: It should be stressed that the Real Time Java Framework exists at presents only as a research prototype. No effort was made to perform a full testing of its functionalities. The aim of the testing programme was simply to give sufficient confidence in the framework correctness to allow its use as a test bed for the use of framework technology built upon Real-Time Java in embedded control systems.

Component-Level Testing in Desktop Environment

Testing at this levels aims at verifying the correctness of individual components. Tests are organized around test cases. A test case is encapsulated in a class derived from the following base abstract class:

public abstract class TestCase {

  . . .

  TestCase(int testId, string testName);

  // To be called before the test starts. Returns false if
  // initialization failed
  public boolean setUpTestCase();

  // To be called to execute the test
  public abstract void runTestCase();

  // To be called after test execution. Returns false if
  // shut down failed
  public boolean shutDownTestCase();

  // Set the test result -- can only be called once!
  public void setTestResult(bool outcome, string failureMessage);
  . . .

};

Test cases are completely self-contained and independent from each other. For each test case, a subclass of TestCase is created. Since most of the framework test cases require the same set up actions to be performed before the test execution begins, a class TestCaseGenericSetUp is provided to perform this common initialization actions and to serve as a convenient base class from which to derive specific test case classes.

The framework defines a large number of test cases that test various aspects of key components. The test case classes are called TestCaseXxx where 'xxx' is either the name of the component to be tested or of the framelet to which the component(s) to be tested belong.

Sequences of test cases can be loaded into a test suite. A test suite allows several test cases to be executed in sequence as a single unit. Test suites are encapsulated in instances of the following class:

public class TestSuite {

  . . .

  // Defines the file to which the test results are sent
  TestSuite(PrintWriter outputFile);

  // Execute all test cases in the test suite
  void runTestSuite();

  // Load a test case in the test suite
  void loadTestCase(TestCase newTestCase);

};

The desktop version of the framework defines a single project called RegressionTest that executes all the test cases predefined by the framework in sequence. This project can be used to perform regression testing on the framework.

Back To Top, Back to Real-Time Java Project Home


System-Level Testing in Desktop Environment

The framework is used to instantiate an application and the application is subjected to open-loop testing in the embedded environment. The application that was used in this project is the so-called Test SMM Application. This application is intended to be as close as possible to the prototype SMM application used for system-level testing in the embedded environment. It differs from the prototype SMM application on in the following respects:

Instantiation of the test SMM application uses the same same instantiation factories as the prototype SMM application with the following exceptions:

The prototype instantiator component JbedSmmInstantiator is replaced with an instantiator component TestSmmInstantiator that is identical to the former except that it uses the test versions of the system and unit factories.

Note that, since telemetry and telecommand data in the prototype application are sent and received through TCP/IP, the same code works in the desktop environment and therefore there is no need to replace the telecommand and telemetry components. As a further consequence, the same ground station simulator can be used both for the prototype and for the test applications. 

The scheduling policy adopted for the test application is the same as for the prototype application. However, since the run-time system in a desktop environment has different characteristics from the Jbed run-time system, application behaviour is not exactly reproducible. The test application is used primarily to verify the functional correctness of the application code. No simulator of the SMM system is available and therefore the tests are performed in open-loop mode.

Back To Top, Back to Real-Time Java Project Home


Component-Level Testing in Embedded Environment

The test cases defined for the component-level testing in the desktop environment are run in the embedded environment.

Back To Top, Back to Real-Time Java Project Home


System-Level Testing in Embedded Environment

The framework is used to instantiate an application and the application is subjected to closed-loop testing in the embedded environment. The application that was used in this project is the prototype SMM application used to control the SMM system and described in another page on this web site. Two versions of the applications were generated based on two different RT Java implementations (JBed by Esmertec and PERC by NewMonics).

Back To Top, Back to Real-Time Java Project Home



Last updated on Apr. 24-th 2003 by Alessandro Pasetti