Difference between revisions of "How TUnit Works"
(New page: There are two components to the TUnit unit testing framework. On the computer end, a Java application is in charge of deciding which tests to run. The Java side of TUnit is the engine wh...) |
|||
| Line 5: | Line 5: | ||
On the embedded side, a TUnit library is added into the compilation of each [http://en.wikipedia.org/wiki/Test_suite Test Suite]. This embedded library commands the user's test application on what to do, and is responsible for maintaining communication with the computer over the serial port. | On the embedded side, a TUnit library is added into the compilation of each [http://en.wikipedia.org/wiki/Test_suite Test Suite]. This embedded library commands the user's test application on what to do, and is responsible for maintaining communication with the computer over the serial port. | ||
| − | This section will give a brief overview of how TUnit works, and [http://docs.tinyos.net/index.php/TUnit other tutorials] will dive in further with details. | + | This section will give a brief overview of how TUnit works, and [http://docs.tinyos.net/index.php/TUnit other tutorials] will dive in further with the details. |
Revision as of 17:44, 20 December 2007
There are two components to the TUnit unit testing framework.
On the computer end, a Java application is in charge of deciding which tests to run. The Java side of TUnit is the engine which compiles the tests, installs the tests to microcontroller hardware, runs the tests, cleans up the tests, and gathers the results. If a test causes the embedded hardware to lock-up, the Java TUnit application will safely timeout and continue on with further testing.
On the embedded side, a TUnit library is added into the compilation of each Test Suite. This embedded library commands the user's test application on what to do, and is responsible for maintaining communication with the computer over the serial port.
This section will give a brief overview of how TUnit works, and other tutorials will dive in further with the details.
TUnit Java Application
TUnit is run from the tunit.jar file, which is checked out with the tinyos-2.x-contrib repository and the rest of the TUnit framework. The tunit.jar file depends on several other .jar files in your Java classpath. The setup of the tunit.jar file, classpath, and dependencies is discussed further in Setting up TUnit.
TUnit's Java application is responsible for running tests. To do this, it relies on a number of elements to help it decide what to do.
Physical nodes must be plugged into the computer. TUnit relies on nodes being plugged in to allow tests to execute on actual hardware, where performance and issues may vary on a per-platform basis. It is difficult to automatically detect what type of hardware is plugged into the computer, especially when variations of hardware exist. To help TUnit out, we have to tell it in an XML file which hardware is plugged in, how to talk to it, and which combinations of hardware we want to test.
The file that tells the TUnit Java application what nodes are connected is the tunit.xml file. There is an example of this file at tinyos-2.x-contrib/tunit/tunit_example.xml. It is left up to developers to create their own tunit.xml file for their own systems. The tunit.xml file is discussed further in the tunit.xml documentation.
