javax.swing.SwingUtilities - new tests

David Gilbert david.gilbert@object-refinery.com
Thu Nov 18 08:57:00 GMT 2004


Michael Koch wrote:
> Am Donnerstag, 18. November 2004 00:52 schrieb Michael Koch:
> 
>>Am Mittwoch, 17. November 2004 23:46 schrieb David Gilbert:
>>
>>>I've committed these new tests:
>>>
>>>2004-11-17  David Gilbert  <david.gilbert@object-refinery.com>
>>>
>>> *
>>>gnu/testlet/javax/swing/SwingUtilities/computeIntersection.java,
>>>gnu/testlet/javax/swing/SwingUtilities/computeUnion.java,
>>>gnu/testlet/javax/swing/SwingUtilities/isRectangleContainingRecta
>>>n gle.java: New tests.
>>>
>>>See the attached patch.
>>
>>+    harness.checkPoint("Null arguments");
>>+    // test null argument - the API spec doesn't specify what
>>should +    // happen, but a NullPointerException is the usual
>>result elsewhere
>>+    try
>>+    {
>>+      /* Rectangle r2 = */ SwingUtilities.computeIntersection(1,
>>2, 3, 4, null);
>>+      harness.check(false);
>>+    }
>>+    catch (NullPointerException e)
>>+    {
>>+      harness.check(true);
>>+    }
>>
>>We spoke about it in private mail. This test gets silently ignored
>>when some exception other then NullPointerException gets thrown.
> 
> Well, wrong again. The framework catches and unexpected exception. 
> Letting the testcase just fail would be more nice.

Thinking about this some more, I don't think it is practical to try to 
catch unexpected exceptions.  It's not so bad in the above example where 
the code being tested is already within a try{} block - all you have to 
do is add an extra catch(Exception e){} - but the same problem exists 
with regular testing code as well.  For example:

   harness.checkPoint("ABC - 1");
   // create some Classpath object, call its methods
   ...  // maybe an unexpected exception gets thrown here
   harness.check(condition1a);
   harness.check(condition1b);

   harness.checkPoint("ABC - 2");
   // do another variation
   ...  // maybe an unexpected exception
   harness.check(condition2a);
   harness.check(condition2b);

To ensure that an unexpected exception in "ABC - 1" doesn't prevent the 
checks in "ABC - 2" from running, you'd need to change the above code to 
something like this:

   harness.checkPoint("ABC - 1");
   try
   {
     // create some Classpath object, call its methods
     ...  // maybe an unexpected exception gets thrown here
   }
   catch (Exception e)
   {
     harness.debug(e);
   }
   harness.check(condition1a);
   harness.check(condition1b);

   harness.checkPoint("ABC - 2");
   try
   {
     // do another variation
     ...  // maybe an unexpected exception
   }
   catch (Exception e)
   {
     harness.debug(e);
   }
   harness.check(condition2a);
   harness.check(condition2b);

The testing code starts to get swamped by the error checking code.

Regards,

Dave



More information about the Mauve-patches mailing list