Difference between revisions of "TUnit Recent Updates"

From TinyOS Wiki
Jump to: navigation, search
(1/16/2008 : PostEditHtml)
(1/10/2008 : Removed testrunner.extra)
 
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
== 3/4/2010 : Run tests without a serial connection, added some secret sauce ==
 +
* TUnit can now run tests on hardware completely over a wireless link, no serial connection is required.  Just leave the "motecom" definition blank and TUnit will not attempt to connect to that node with a serial connection.
 +
* The HTML reports can be skinned using your company or organization's logo.  Just drop an image named "logo.jpg" into the /reports directory and run the TUnit Report task ("ant tunitreport" if you have your build.xml file available).  The image will automatically be included in your HTML reports.
 +
 +
== 2/22/2010 : More features ==
 +
* TUnit now looks for a log4j.xml file next to your tunit.xml file.  This can specify how you want TUnit to print output to the console.
 +
* "make myplatform reinstall.0" is now being logged as a test.  If the reinstall fails, TUnit will log an error and quit the test immediately.
 +
* TUnit now clears out the global pass/fail/error counts when you begin its execution.  This is useful when there is another Java application accessing TUnit directly and running it multiple times.
 +
 +
== 7/21/2008 : Statistics Compile Error ==
 +
 +
Fixed a compilation error that prevents statistics from being logged correctly.
 +
 +
 +
== 6/10/2008 : Report directory fixes ==
 +
 +
The names of the report/package directories used to be bad.  If you were executing TUnit outside of tinyos-2.x-contrib, reports would be placed in the wrong locations with the wrong names.  Lots of the statistics and package directory naming issues have been fixed.
 +
 +
 +
== 6/09/2008 : @cmd flags activated ==
 +
 +
You can now run external commands in tunit. TUnit must started up with the -enablecmd flag to enable external @cmd's. 
 +
 +
The <code>@cmd run</code> suite.properties flag will execute after the command is given to the embedded side to start the test, and can run as long as needed because the timeout timer does not start until afterward.  If you are using this command to run some external measurement equipment, you can simply have your embedded test reply immediately with a "done()".  With the embedded side preemptively finished with its job, the test will complete when the external program finishes executing.
 +
 +
In the "start", "run", and "stop" @cmd flags, an exit value > 0 will be recorded as a test failure, while an exit value of 0 is success.  All test output to the command line from the external program will be stored in the test results for failures.  This allows your external measurement equipment to assert success or fail with some descriptive output.
 +
 +
Example suite.properties file:
 +
 +
  @exactnodes 1
 +
  @only blaze
 +
  @cmd start WaitForUser.exe
 +
  @cmd run TakeCurrentMeasurement.exe
 +
  @cmd stop NotifyGui.exe
 +
 
 +
 +
 +
== 6/08/2008 : CmdExec Cross-platform Compatibility ==
 +
* Merged in Miklos Maroti's and Matthias Woehrle's CmdExec code, got it working under Window/Cygwin again.  Hopefully this will better support a wider range of OS's:  Linux/Ubuntu, Mac, Windows/Cygwin.  There are a few upgrades to CmdExec:
 +
** Takes in an environment variable String.  We tack in all CFLAGS into an environment variable which is then pulled in by tunit.extra.  This way we can use .extra files as well as setup compiler definitions/includes without conflict.
 +
** Properly tokenizes commands. The default tokenizer in Java's exec command will break up things inside of quotes.  This is bad for us.
 +
** Removed the manual -I options specified by TUnit, which were duplicated in the tunit.extra file.  This requires you to have a tunit.extra file in make/support, and make sure it has the correct -I options inside.
 +
 +
 +
== 6/03/2008 : -tunitxml, -enablecmd, @cmd flag ==
 +
 +
* Added a -tunitxml option to the main TUnit executable to define where the tunit.xml file is located.
 +
* Added an -enablecmd option to the main TUnit executable to allow command line arguments to execute from the @cmd flag in suite.properties files.
 +
* Added a @cmd flag to the suite.properties files to run external applications before, during, and after a test. This is intended to allow a test to run external test equipment during the test or prompt for user interaction before or after the test executes. This may be very os-dependent and intended to be used in custom automated test setups.
 +
** @cmd start <command> : Runs the <command> before the test begins.  Blocking.
 +
** @cmd run <command> : Runs the <command> after the embedded test has begun.
 +
** @cmd stop <command> : Runs the <command> after the test completes.  Blocking.
 +
 +
 +
== 6/02/2008 : @compile ==
 +
 +
Added a @compile option to suite.properties. 
 +
* Always
 +
** Default option. Always compile at least one time per test run.
 +
 +
* Once
 +
** Only compile if the build doesn't already exist.
 +
 +
* Never
 +
** Compile manually
 +
 +
 +
== 4/17/2008 : XML Parsing ==
 +
 +
Fixed an issue where XML files could not convert to HTML files through Ant due to XML parsing errors.
 +
 +
== 2/10/2008 : Removed testrunner.extra ==
 +
 +
Due to an incompatibility issue Miklos brought up, we added tunit.extra to the tinyos-2.x/support/make directory which now has the line:
 +
 +
  CFLAGS += $(TUNITCFLAGS)
 +
 +
CFLAGS are now brought in through this TUNITCFLAGS variable, while still allowing .extra files to compile in with the rest of the system.  You can now compile most TUnit applications standalone by typing:
 +
 +
  $ make telosb tunit
 +
 +
The TUnit Java application will populate the TUNITCFLAGS variable through the suite.properties @cflags and @extra definitions. The resulting Make command line looks something like:
 +
 +
  '''suite.properties'''
 +
    @cflags -DLOW_POWER_LISTENING
 +
    @cflags CFLAGS+=-I../../
 +
 +
  $ make telosb tunit TUNITCFLAGS="-DLOW_POWER_LISTENING -I../../"
 +
 +
== 1/29/2008 : Failed logging output ==
 +
 +
Modified the way failure text is printed to the screen while executing TUnit to make it easier to read.
 +
 +
== 1/23/2008 : tunit.extra ==
 +
 +
Modified the tunit.extra file to reference directories from $(TOSCONTRIB)/tunit instead of $(TUNIT_BASE).
 +
 +
== 1/18/2008 : @extra / @cflags ==
 +
 +
Added a @cflags option to the [[suite.properties]]. The @extra option will now look for CFLAGS+=..., and if it finds it, will add it to the list of CFLAGS.  All @cflags will be written to the testrunner.extra file, while the @extra options get written to the command line.  Ideally, you should only reference .extra files with the @extra option.  You can also make a local whatever.extra file and reference it from @extra whatever in suite.properties.
 +
 +
  The following all mean the same thing:
 +
 
 +
    @extra lpl
 +
    @extras lpl
 +
    @extra CFLAGS+=-DLOW_POWER_LISTENING
 +
    @extras CFLAGS+=-DLOW_POWER_LISTENING
 +
    @cflags -DLOW_POWER_LISTENING
 +
    @cflag -DLOW_POWER_LISTENING
 +
    @cflag CFLAGS+=-DLOW_POWER_LISTENING
 +
    @cflags CFLAGS+=-DLOW_POWER_LISTENING
 +
 
== 1/16/2008 : testrunner.extra ==
 
== 1/16/2008 : testrunner.extra ==
  
Line 7: Line 119:
 
To allow nesC to pull in this .extra file from your local application directory, you '''MUST''' have your TOSMAKE_PATH environment variable include ./ like this:
 
To allow nesC to pull in this .extra file from your local application directory, you '''MUST''' have your TOSMAKE_PATH environment variable include ./ like this:
  
   export TOSMAKE_PATH="./"
+
   '''export TOSMAKE_PATH="./"'''
  
 
Without doing this, TUnit will not be able to compile in the CFLAGS definitions from the locally created testrunner.extra file, and the compiler will complain about not being able to find TUnit library files like TestCaseC and TestCase.h.
 
Without doing this, TUnit will not be able to compile in the CFLAGS definitions from the locally created testrunner.extra file, and the compiler will complain about not being able to find TUnit library files like TestCaseC and TestCase.h.

Latest revision as of 01:12, 4 March 2010

3/4/2010 : Run tests without a serial connection, added some secret sauce

  • TUnit can now run tests on hardware completely over a wireless link, no serial connection is required. Just leave the "motecom" definition blank and TUnit will not attempt to connect to that node with a serial connection.
  • The HTML reports can be skinned using your company or organization's logo. Just drop an image named "logo.jpg" into the /reports directory and run the TUnit Report task ("ant tunitreport" if you have your build.xml file available). The image will automatically be included in your HTML reports.

2/22/2010 : More features

  • TUnit now looks for a log4j.xml file next to your tunit.xml file. This can specify how you want TUnit to print output to the console.
  • "make myplatform reinstall.0" is now being logged as a test. If the reinstall fails, TUnit will log an error and quit the test immediately.
  • TUnit now clears out the global pass/fail/error counts when you begin its execution. This is useful when there is another Java application accessing TUnit directly and running it multiple times.

7/21/2008 : Statistics Compile Error

Fixed a compilation error that prevents statistics from being logged correctly.


6/10/2008 : Report directory fixes

The names of the report/package directories used to be bad. If you were executing TUnit outside of tinyos-2.x-contrib, reports would be placed in the wrong locations with the wrong names. Lots of the statistics and package directory naming issues have been fixed.


6/09/2008 : @cmd flags activated

You can now run external commands in tunit. TUnit must started up with the -enablecmd flag to enable external @cmd's.

The @cmd run suite.properties flag will execute after the command is given to the embedded side to start the test, and can run as long as needed because the timeout timer does not start until afterward. If you are using this command to run some external measurement equipment, you can simply have your embedded test reply immediately with a "done()". With the embedded side preemptively finished with its job, the test will complete when the external program finishes executing.

In the "start", "run", and "stop" @cmd flags, an exit value > 0 will be recorded as a test failure, while an exit value of 0 is success. All test output to the command line from the external program will be stored in the test results for failures. This allows your external measurement equipment to assert success or fail with some descriptive output.

Example suite.properties file:

 @exactnodes 1
 @only blaze
 @cmd start WaitForUser.exe
 @cmd run TakeCurrentMeasurement.exe
 @cmd stop NotifyGui.exe
 


6/08/2008 : CmdExec Cross-platform Compatibility

  • Merged in Miklos Maroti's and Matthias Woehrle's CmdExec code, got it working under Window/Cygwin again. Hopefully this will better support a wider range of OS's: Linux/Ubuntu, Mac, Windows/Cygwin. There are a few upgrades to CmdExec:
    • Takes in an environment variable String. We tack in all CFLAGS into an environment variable which is then pulled in by tunit.extra. This way we can use .extra files as well as setup compiler definitions/includes without conflict.
    • Properly tokenizes commands. The default tokenizer in Java's exec command will break up things inside of quotes. This is bad for us.
    • Removed the manual -I options specified by TUnit, which were duplicated in the tunit.extra file. This requires you to have a tunit.extra file in make/support, and make sure it has the correct -I options inside.


6/03/2008 : -tunitxml, -enablecmd, @cmd flag

  • Added a -tunitxml option to the main TUnit executable to define where the tunit.xml file is located.
  • Added an -enablecmd option to the main TUnit executable to allow command line arguments to execute from the @cmd flag in suite.properties files.
  • Added a @cmd flag to the suite.properties files to run external applications before, during, and after a test. This is intended to allow a test to run external test equipment during the test or prompt for user interaction before or after the test executes. This may be very os-dependent and intended to be used in custom automated test setups.
    • @cmd start <command> : Runs the <command> before the test begins. Blocking.
    • @cmd run <command> : Runs the <command> after the embedded test has begun.
    • @cmd stop <command> : Runs the <command> after the test completes. Blocking.


6/02/2008 : @compile

Added a @compile option to suite.properties.

  • Always
    • Default option. Always compile at least one time per test run.
  • Once
    • Only compile if the build doesn't already exist.
  • Never
    • Compile manually


4/17/2008 : XML Parsing

Fixed an issue where XML files could not convert to HTML files through Ant due to XML parsing errors.

2/10/2008 : Removed testrunner.extra

Due to an incompatibility issue Miklos brought up, we added tunit.extra to the tinyos-2.x/support/make directory which now has the line:

 CFLAGS += $(TUNITCFLAGS)

CFLAGS are now brought in through this TUNITCFLAGS variable, while still allowing .extra files to compile in with the rest of the system. You can now compile most TUnit applications standalone by typing:

 $ make telosb tunit

The TUnit Java application will populate the TUNITCFLAGS variable through the suite.properties @cflags and @extra definitions. The resulting Make command line looks something like:

 suite.properties
   @cflags -DLOW_POWER_LISTENING
   @cflags CFLAGS+=-I../../
 $ make telosb tunit TUNITCFLAGS="-DLOW_POWER_LISTENING -I../../"

1/29/2008 : Failed logging output

Modified the way failure text is printed to the screen while executing TUnit to make it easier to read.

1/23/2008 : tunit.extra

Modified the tunit.extra file to reference directories from $(TOSCONTRIB)/tunit instead of $(TUNIT_BASE).

1/18/2008 : @extra / @cflags

Added a @cflags option to the suite.properties. The @extra option will now look for CFLAGS+=..., and if it finds it, will add it to the list of CFLAGS. All @cflags will be written to the testrunner.extra file, while the @extra options get written to the command line. Ideally, you should only reference .extra files with the @extra option. You can also make a local whatever.extra file and reference it from @extra whatever in suite.properties.

 The following all mean the same thing:
 
   @extra lpl
   @extras lpl
   @extra CFLAGS+=-DLOW_POWER_LISTENING
   @extras CFLAGS+=-DLOW_POWER_LISTENING
   @cflags -DLOW_POWER_LISTENING
   @cflag -DLOW_POWER_LISTENING
   @cflag CFLAGS+=-DLOW_POWER_LISTENING
   @cflags CFLAGS+=-DLOW_POWER_LISTENING

1/16/2008 : testrunner.extra

TUnit was having problems with @extra CFLAGS+=-I... being written to the make command line, while pulling in .extra files elsewhere. The .extra files wouldn't get accessed.

To solve this, TUnit now prevents CFLAGS+=-I... being written to the make command line. Instead, it writes a temporary file in your local directory called "testrunner.extra" which is deleted after the compile is complete.

To allow nesC to pull in this .extra file from your local application directory, you MUST have your TOSMAKE_PATH environment variable include ./ like this:

 export TOSMAKE_PATH="./"

Without doing this, TUnit will not be able to compile in the CFLAGS definitions from the locally created testrunner.extra file, and the compiler will complain about not being able to find TUnit library files like TestCaseC and TestCase.h.

1/16/2008 : PostEditHtml

  • The PostEditHtml Java application in tunit.jar (com.rincon.tunitposthtml.PostEditHtml) now provides the same command line arguments as TUnit itself, allowing you to select a report directory to post-edit.
  • The TOSCONTRIB environment variable is now looked for before the TUNIT_BASE environment variable, since TOSCONTRIB is default.
  • Added in initial 2 second delays during sf.connect() cycles to try to reduce the ping/pong dropped issues.

1/15/2008 : Line Numbers

TUnit now reports the filename and line number each assertion originated from. These line numbers are displayed for both successes and failures in the HTML reports and during execution.

TUnit also displays a list of failures at the end of execution that now include line numbers.