Why does TestNG allow several expected exceptions?

Question

Why does TestNG have the possibility to check if one of several exceptions are thrown? As far as I know, JUnit only supports one expected exception. Consider the following TestNG dummy examples where both tests will pass:

@Test(expectedExceptions = { NullPointerException.class, IllegalArgumentException.class })
public void throwsNullPointer() {
    throw new NullPointerException();
}

@Test(expectedExceptions = { NullPointerException.class, IllegalArgumentException.class })
public void throwsIllegalArgument() {
    throw new IllegalArgumentException();
}

My initial feeling is that it should be possible to derive from the code under test exactly which exception that is expected. However, there must be some design decision from the people behind TestNG.

Is it perhaps support for testing code with random features that cannot be mocked away? Does anybody have an idea, and preferably a real-life scenario?

Answer 1

Why does TestNG allow several expected exceptions?

I think that the most likely reason is that people asked for the feature ... and it is a reasonable thing to provide.

I can think of a few use-cases.

• It may be needed when writing tests for code that is non-deterministic, and the non-determinism affects the exceptions thrown.

• It may be needed when testing multiple implementations of an API which may behave differently wrt to thrown exceptions. The implementations could be different classes or different versions of the same class.

• It may be needed when testing code that depends on 3rd-party software, and has to cope with multiple versions of that software with different behaviour that is visible to the test.

• It may be needed when doing "black box" testing of an API where the interface specification is unclear.

---

My initial feeling is that it should be possible to derive from the code under test exactly which exception that is expected.

That assumes that you have access to the source code. Also, adapting the tests to the code is missing the point that you should be testing against the specification rather than the code.

If you have the option of allowing multiple exceptions, you avoid this. (And you don't have this option, then you (the test writer) have to catch and test for exceptions within the testcase ... if multiple exceptions are possible.)