This is the mail archive of the mauve-patches@sources.redhat.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: javax.swing.SwingUtilities - new tests


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]