leJOSUnit 1.0.2 - Implementation Details

Overview

October 1 2003

Contents

• Prerequisites
• Porting details
• Restrictions compared with JUnit
• Footprint of leJOSUnit
• Planned extensions

Prerequisites

• leJOS 2.0.0 should contain following patch of jtools/js/tinyvm/CodeUtilities: (search for OP_LDC:) If this patch is missing, compile error can raise up with a message, that there are too many constants.

          case OP_LDC:
            // Bug reported by Jochen Hiller, fixed by Lawrie Griffiths
            // convert aCode[i] not to an int, mask it to an unsigned byte instead
            // pOutCode[i] = (byte) processConstantIndex ((int) aCode[i]);
            pOutCode[i] = (byte) processConstantIndex (aCode[i] & 0xFF);
            i++;
            break;
          

• leJOS 2.1.0 does contain this patch yet, will work without any problems.

Porting details

• The leJOSUnit has been ported using the JUnit version 3.8.1
• More than 98% of the leJOSUnit development has been done within the emulator. Thanks for its capabilities.
• leJOSUnit provides a RCX specific lejosunit.rcxui.TestRunner, which enables leJOS to start tests using the RCX buttons, and display useful output on the very simple text display.
• All Java reflection related code parts have been removed, due to missing support within leJOS.
• The leJOS implementation of StringBuffer uses the Math library, which will increase the size of the linked program for some kBytes. Implicitely, Java will use the class StringBuffer for String operations like
      String s = "abc" + "def" + "123";.
  Therefore, leJOSUnit has been designed NOT to use such String concatenations. The class lesjosunit.util.Util implements some simple String concatenations for 2 and 3 arguments based on arraycopy.
  Question: Does leJOS support some diagnostic output as part of the linker, to identify which classes require other classes ?
• To build leJOSUnit from scratch, you have to set the link to the leJOS installation within the build.xml file

Restrictions compared with JUnit

• Class Assert: Does not support assertEquals methods for argument types double, Double and Long.
• Class Assert: Does not support assertEquals(String, String) and assertEquals(String, String, String), as they print out a specialiced format in JUnit. This cannot be supported within the limited text display. Therefore, class ComparisonFailure has not been implemented.
• The class Assert has been designed, to avoid dependencies to class StringBuffer, as this would require the Math class, and would increase the required footprint.
• The methods assertEquals(float, float, float) and assertEquals(String, float, float, float) are implemented by the class FloatAssert. FloatAssert uses the class StringBuffer, which requires the Math libary.
• The class TestSuite does not support a name.
• The class TestResult does support only ONE TestListener, to avoid Vector handling.
• All Java reflection related methods have been removed from class TestSuite.
• Removed some not required methods from class TestSuite.
• The class TestCase does not implement any deprecated methods.

Footprint of leJOSUnit

leJOSUnit includes some tests (see package lejosunit.tests.size), to compare the required executable without leJOSUnit and including leJOSUnit.

Footprint of leJOSUnit based on leJOS 2.1

In leJOS 2.1, there is less footprint, due to the enhanced optimized linker, which removes also not used methods.

Footprint of leJOSUnit based on leJOS 2.0

This is based on leJOS 2.0, which includes an optimized linker, removing not required classes.

Planned extensions / TODO's

leJOS related

• Util.arraycopy(char[], int, char[], int, int) should be provided by the core leJOS environment in System.arraycopy(char[], int, char[], int, int), as this can be a general useful function. At the moment (leJOS 2.0), it is in package scope and cannot be used outside of java.lang. This would decrease the required code size.

  Question: class Vector also implements a method arraycopy(Object[], int, Object[], int, int). Can this be consolidated ?

  Proposal: Make System.arraycopy(char[], int, char[], int, int) a public method ! Consolidate with Vector.arraycopy(Object[], int, Object[], int, int), to use Object[] instead of char[] argument type. Does it make sense, to implement this as a native method ?

• Check leJOS for a bug in class StringBuffer. This code fails:

            int i = 1;
            StringBuffer sbuf = new StringBuffer();
            sbuf.append (i); // this code fails
            sbuf.append (new Integer (i)); // this code works
          

• Check, why simple use of a Button will create an instance of a poller. Will load Poll, ListenerThread, and other classes

leJOSUnit related

• Write a small cookbook to explain how to use leJOSUnit the best way.
• Provide a RemoteTestRunner, running at PC side, and a TestRunnerServer running at RCX.
• Provide more detailed information when an exception has been raised. Requires more detailed information from the virtual machine. Can be display with a stack trace (hopefully) at RemoteTestRunner.
• Use some internal leJOS information (class id's, method id's) from the virtual machine if supported. This could enable a small reflection support too ?
• Port the JUnit original test suite from JUnit to leJOSUnit ?
• Support some golden test cases for the emulator, whereas the output created by the emulator can be compared against a reference output.
• Add a logo for leJOSUnit. Combine JU with leJOS logo. Link to SF site.
• Support constructors for a test based on byte, instead of String. Will decrease footprint.