The eCos kernel and other packages have test suites that rigorously exercise the available features and confirm correct execution. The tests are run on many different possible configurations, but the high number of configuration permutations makes it impossible to test them all. The use of test suites is particularly important for embedded systems, where software robustness is a priority. All eCos software is tested prior to shipping, but if you define your own configuration, you will probably want to verify that the test cases work for it.
This release includes test suites for the eCos kernel, kernel C API, C library, ITRON compatibility, and device driver packages. The use of the test suites is similar for all packages. The tests are supplied as source code for building with your specific eCos configurations. The test case source code is located under the base source directory BASE_DIR/packages/:
There may be additional tests found in other packages.
Each test suite consists of a number of test cases which can be executed individually. A test case may involve one or more individual tests of the package's features. Successful completion of each test within the test case is reported as a line of text that is sent to the diagnostic channel (usually the serial port) for display on a terminal or terminal emulator.
Each test case runs only once and usually requires target hardware to be reset on completion. Note that certain test cases may not terminate immediately, especially if they involve delays and run on a target simulator.
Using the eCos Configuration Tool it is possible to automate the downloading and execution of tests with the appropriately configured eCos packages. To do so, compile and link the test cases by using the Build->Tests menu item, after which the tests can be downloaded and executed by selecting Tools->Run Tests .
The Run button is used to initiate a test run. Those tests selected on the Executables tab are run, and the output recorded on the Output and Summary tabs. During the course of a run, the Run button changes to Stop . This button may be used to interrupt a test run at any point.
Running the test manually is done simply by invoking GDB, connecting to the target, downloading the test, optionally setting some breakpoints, and then running the test. All this was covered in Target Setup .
Since the serial line is also used for communication with GDB, a filter is inserted in the communication pathway between GDB and the serial device which is connected to the hardware target. The filter forwards all communication between the two, but also listens for special commands embedded in the data stream from the target.
When such a command is seen, the filter stops forwarding data to GDB from the target and enters a special mode. In this mode the test case running on the target is able to control the filter, commanding it to run various tests. While these tests run, GDB is isolated from the target.
In theory, it is possible to extend the filter to provide a generic framework for other target-external testing components, thus decoupling the testing infrastructure from the (possibly limited) communication means provided by the target (serial, JTAG, Ethernet, etc).