When writing unit tests for a Java API there may be circumstances where you want to perform more detailed validation of an exception. I.e. more than is offered by the #test annotation offered by JUnit.
For example, consider an class that should catch an exception from some other Interface, wrap that exception and throw the wrapped exception. You may want to verify:
The exact method call that throws the wrapped exception.
That the wrapper exception has the original exception as its cause.
The message of the wrapper exception.
The main point here is that you want to be perf additional validation of an exception in a unit test (not a debate about whether you should verify things like the exception message).
What's a good approach for this?
In JUnit 4 it can be easily done using ExpectedException rule.
Here is example from javadocs:
// These tests all pass.
public static class HasExpectedException {
#Rule
public ExpectedException thrown = ExpectedException.none();
#Test
public void throwsNothing() {
// no exception expected, none thrown: passes.
}
#Test
public void throwsNullPointerException() {
thrown.expect(NullPointerException.class);
throw new NullPointerException();
}
#Test
public void throwsNullPointerExceptionWithMessage() {
thrown.expect(NullPointerException.class);
thrown.expectMessage("happened?");
thrown.expectMessage(startsWith("What"));
throw new NullPointerException("What happened?");
}
}
As provided in your answer, it's a good approach. In addition to this:
You could wrap the function expectException into a new Annotation, called ExpectedException.
An annotated method would look like this:
#Test
#ExpectedException(class=WrapperException.class, message="Exception Message", causeException)
public void testAnExceptionWrappingFunction() {
//whatever you test
}
This way would be more readable, but it's exactly the same approach.
Another reason is: I like Annotations :)
Looking at the proposed answers, you can really feel the pain of not having closures in Java. IMHO, the most readable solution is ye good old try catch.
#Test
public void test() {
...
...
try {
...
fail("No exception caught :(");
}
catch (RuntimeException ex) {
assertEquals(Whatever.class, ex.getCause().getClass());
assertEquals("Message", ex.getMessage());
}
}
For JUNIT 3.x
public void test(){
boolean thrown = false;
try{
mightThrowEx();
} catch ( Surprise expected ){
thrown = true;
assertEquals( "message", expected.getMessage());
}
assertTrue(thrown );
}
Until this post I've done my exception validation by doing this:
try {
myObject.doThings();
fail("Should've thrown SomeException!");
} catch (SomeException e) {
assertEquals("something", e.getSomething());
}
I spent a few moments thinking about the issue though and came up with the following (Java5, JUnit 3.x):
// Functor interface for exception assertion.
public interface AssertionContainer<T extends Throwable> {
void invoke() throws T;
void validate(T throwable);
Class<T> getType();
}
// Actual assertion method.
public <T extends Throwable> void assertThrowsException(AssertionContainer<T> functor) {
try {
functor.invoke();
fail("Should've thrown "+functor.getType()+"!");
} catch (Throwable exc) {
assertSame("Thrown exception was of the wrong type! Expected "+functor.getClass()+", actual "+exc.getType(),
exc.getClass(), functor.getType());
functor.validate((T) exc);
}
}
// Example implementation for servlet I used to actually test this. It was an inner class, actually.
AssertionContainer<ServletException> functor = new AssertionContainer<ServletException>() {
public void invoke() throws ServletException {
servlet.getRequiredParameter(request, "some_param");
}
public void validate(ServletException e) {
assertEquals("Parameter \"some_param\" wasn't found!", e.getMessage());
}
public Class<ServletException> getType() {
return ServletException.class;
}
}
// And this is how it's used.
assertThrowsException(functor);
Looking at these two I can't decide which one I like more. I guess this is one of those issues where achieving a goal (in my case, the assertion method with functor parameter) isn't worth it in the long run since it's just a lot easier to do those 6+ of code to assert the try..catch block.
Then again, maybe my 10 minute result of problem solving at friday evening just isn't the most intelligent way to do this.
#akuhn:
Even without closures we can get a more readable solution (using catch-exception):
import static com.googlecode.catchexception.CatchException.*;
public void test() {
...
...
catchException(nastyBoy).doNastyStuff();
assertTrue(caughtException() instanceof WhateverException);
assertEquals("Message", caughtException().getMessage());
}
The following helper method (adapted from this blog post) does the trick:
/**
* Run a test body expecting an exception of the
* given class and with the given message.
*
* #param test To be executed and is expected to throw the exception.
* #param expectedException The type of the expected exception.
* #param expectedMessage If not null, should be the message of the expected exception.
* #param expectedCause If not null, should be the same as the cause of the received exception.
*/
public static void expectException(
Runnable test,
Class<? extends Throwable> expectedException,
String expectedMessage,
Throwable expectedCause) {
try {
test.run();
}
catch (Exception ex) {
assertSame(expectedException, ex.getClass());
if (expectedMessage != null) {
assertEquals(expectedMessage, ex.getMessage());
}
if (expectedCause != null) {
assertSame(expectedCause, ex.getCause());
}
return;
}
fail("Didn't find expected exception of type " + expectedException.getName());
}
The test code can then invoke this as follows:
TestHelper.expectException(
new Runnable() {
public void run() {
classInstanceBeingTested.methodThatThrows();
}
},
WrapperException.class,
"Exception Message",
causeException
);
i did something very simple
testBla(){
try {
someFailingMethod()
fail(); //method provided by junit
} catch(Exception e) {
//do nothing
}
}
For JUnit 5 it is much easier:
#Test
void testAppleIsSweetAndRed() throws Exception {
IllegalArgumentException ex = assertThrows(
IllegalArgumentException.class,
() -> testClass.appleIsSweetAndRed("orange", "red", "sweet"));
assertEquals("this is the exception message", ex.getMessage());
assertEquals(NullPointerException.class, ex.getCause().getClass());
}
By returning the exception object itself, assertThrows() allows you to test every aspect regarding your thrown exceptions.
I made a helper similar to the other posted ones:
public class ExpectExceptionsExecutor {
private ExpectExceptionsExecutor() {
}
public static void execute(ExpectExceptionsTemplate e) {
Class<? extends Throwable> aClass = e.getExpectedException();
try {
Method method = ExpectExceptionsTemplate.class.getMethod("doInttemplate");
method.invoke(e);
} catch (NoSuchMethodException e1) {
throw new RuntimeException();
} catch (InvocationTargetException e1) {
Throwable throwable = e1.getTargetException();
if (!aClass.isAssignableFrom(throwable.getClass())) {
// assert false
fail("Exception isn't the one expected");
} else {
assertTrue("Exception captured ", true);
return;
}
;
} catch (IllegalAccessException e1) {
throw new RuntimeException();
}
fail("No exception has been thrown");
}
}
And the template the client should implement
public interface ExpectExceptionsTemplate<T extends Throwable> {
/**
* Specify the type of exception that doInttemplate is expected to throw
* #return
*/
Class<T> getExpectedException();
/**
* Execute risky code inside this method
* TODO specify expected exception using an annotation
*/
public void doInttemplate();
}
And the client code would be something like this:
#Test
public void myTest() throws Exception {
ExpectExceptionsExecutor.execute(new ExpectExceptionsTemplate() {
#Override
public Class getExpectedException() {
return IllegalArgumentException.class;
}
#Override
public void doInttemplate() {
riskyMethod.doSomething(null);
}
});
}
It looks really verbose but if you use an IDE with good autocompletion you will only need to write the type of exception and the actual code under test. (the rest will be done by the IDE :D)
Related
This code gives me a compile error on the line processBatch(batch, this::backupMetacard); The process batch method wraps the consumer in a try/catch block, but Java will not compile the call.
private synchronized void drain() {
for (List<Metacard> batch : Lists.partition(metacards, BATCH_SIZE)) {
getExecutor().submit(() -> {
processBatch(batch, this::backupMetacard);
});
}
metacards.clear();
}
void processBatch(List<Metacard> metacards, Consumer<Metacard> operation) {
List<String> errors = new ArrayList<>();
for (Metacard metacard : metacards) {
try {
operation.accept(metacard);
} catch (IOException e) {
errors.add(metacard.getId());
}
}
if (!errors.isEmpty()) {
LOGGER.info("Plugin processing failed. This is allowable. Skipping to next plugin.",
pluginExceptionWith(errors));
}
}
private void backupMetacard(Metacard metacard) throws IOException {...}
The problem is that in the following snippet, the method backupMetacard declares to throw the checked IOException.
getExecutor().submit(() -> {
processBatch(batch, this::backupMetacard);
^^^^^^^^^^^^^^^^^^^^ // <-- this throws a checked exception
});
As such, it does not comply anymore with the contract of the functional method of Consumer, which is apply and doesn't declare to throw checked exceptions.
Wrap this into a try-catch, where you can throw an unchecked exception instead UncheckedIOException:
getExecutor().submit(() -> {
processBatch(batch, metacard -> {
try {
backupMetacard(metacard);
} catch (IOException e) {
throw new UncheckedIOException(e);
}
});
});
Consumer.accept() does not declare an exception whereas your backupMetacard method does, so you can't pass this::backupMetacard as Consumer parameter.
You can have an adapter functional interface
interface ConsumerX<T>
{
void consumeX(T) throws Exception;
void default consume(T t)
{
try{ consumeX(t); }
catch.... // handle exception
}
}
And use it like
processBatch( batch, (ConsumerX<Metacard>)this::backupMetacard )
The type argument <Metacard> seems redundant, unfortunately it's needed in current Java. We could however have a helper method instead
static <T> ConsumerX<T> of(ConsumerX<T> c){ return c; }
processBatch( batch, ConsumerX.of(this::backupMetacard) )
There are more things to consider. Currently, ConsumerX throws a fixed, overreaching Exception. We would rather have it throw the same exception that the lambda body throws, i.e. exception transparency. This could be done by consumeX() throws a type variable.
Another thing is to provide custom exception handling, e.g.
ConsumerX.of( lambda, ex->{ ... } )
or my preferred syntax --
ConsumerX.of(...).catch_(FooException.class, fe->{ ... });
Below are snippet codes that is basically wrapped try-catch block and being consumed Exception object.
public static <T> T unchecked(final ExceptionBearingAction<T> template, Consumer<Exception> exceptionConsumer) {
T results = null;
try {
results = template.doAction();
} catch (Exception ex) {
exceptionConsumer.accept(ex);
}
return results;
}
ExceptionBearingAction.Java - It's a Functional Interface that perform and Exception bearing action.
#FunctionalInterface
public interface ExceptionBearingAction<T> {
T doAction() throws Exception;
}
How to used it
unchecked(() -> Files.copy(srcPath, Paths.get(distFileUrl), StandardCopyOption.REPLACE_EXISTING), (ex) -> LOGGER.warn("Oops!! copy failed due to {}", ex));
You can do it with apache commons-lang3 library.
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/function/Failable.html
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.12.0</version>
</dependency>
Change method: processBatch
void processBatch(List<Metacard> metacards, FailableConsumer<Metacard, IOException> operation) {
List<String> errors = new ArrayList<>();
for (Metacard metacard : metacards) {
try {
operation.accept(metacard);
} catch (IOException e) {
errors.add(metacard.getId());
}
}
if (!errors.isEmpty()) {
LOGGER.info("Plugin processing failed. This is allowable. Skipping to next plugin.",
pluginExceptionWith(errors));
}
}
I need to test a constructor which throws an exception using JUnit.
Below is the constructor:
public EISThirdPartyClient(ClientConfiguration _config, String _serviceURL)
throws EISClientException {
super(_config, _serviceURL);
try {
ObjectMapperHolder.initialize(_config);
} catch (Exception e) {
throw new EISClientException(e);
}
}
Below is the test case:
#Test
public void testEISThirdPartyClientConctructor() throws EISClientException {
#SuppressWarnings("unused")
EISThirdPartyClient client = new EISThirdPartyClient(new ClientConfiguration(), "url");
boolean caughtException = false;
try {
ObjectMapperHolder.initialize(null);
} catch (Exception ex) {
if (ex instanceof EISClientException) {
caughtException = true;
assertTrue(ex.getCause() instanceof EISClientException);
} else {
ex.printStackTrace();
fail("Uncaught exception");
}
}
assertTrue(caughtException);
}
I am getting java.lang.AssertionError, which isn't what I'm expecting. Can someone tell me what I am doing wrong?
You're testing the wrong thing - you want to ensure that the construction of your object fails, not that it bails out when ObjectMapperHolder bails out.
You can also greatly simplify the test - you can expect that EISClientException is thrown without needing to do any further validation of the exception.
The main point is to get the test to fail with the minimum required amount of work. It seems that passing null as your configuration might do it, so here's an example with that:
#Test(expected = EISClientException.class)
public void testEISThirdPartyClientConctructor() throws EISClientException {
new EISThirdPartyClient(null, "url");
}
If this doesn't quite suit your needs, you may want to look into a mocking framework like Mockito to provide behavior when you are in the critical section of your code.
method which throws at first and second call:
public void foo() throws Exception
test:
#test
public void testFooThrowsAtFirstAndSecondTime(){
boolean thrown;
try {
foo();
} catch (Exception e) {
thrown = true;
}
assertTrue(thrown);
thrown = false;
try {
foo();
} catch (Exception e) {
thrown = true;
}
assertTrue(thrown);
foo();
}
Could you help me find a better solution for this?
Use of Mockito for a better solution would be also acceptable.
With better i mean, if i could avoid try/catch or even multiple try/catch in my test. In other languages or in jAssert i think even in spring there are statements like:
assertThrows(method(..)) //PseudoCode
I thought with Mockito or JUnit 4.x there is a similar thing.
I know about
#Test(expected=Exception)
But this would only be acceptable if i expect one throw and the test ends after that.
I don't think a one-liner per method invocation is possible.
I would write the test like this:
#Test
public void testFooThrowsAtFirstAndSecondTime() throws Exception {
try {
foo();
fail("foo did not throw an exception");
} catch (Exception ex) { }
try{
foo();
fail("foo did not throw an exception");
} catch (Exception ex) { }
foo();
}
The key here is that the try block is crucial if you want to resume execution after an exception. You can factor it out into a method or library, but it has to be called within your test method.
Things that work:
The tried-and-true fail() idiom that you and nrainier cite, which I prefer:
try {
foo();
fail("foo did not throw an exception");
} catch (Exception ex) { }
catch-exception is a library that, like Mockito, wraps the passed object and puts a try block around each method. Mockito's caveats about final methods and classes apply here too, so this won't always work.
List myList = new ArrayList();
catchException(myList).get(1); // myList is wrapped here
assert caughtException() instanceof IndexOutOfBoundsException;
Note that catch-exception is in "maintenance mode" because the Java 8 solution (below) is much more solid.
Any solution like assertThrows(() -> methodThatThrows()) (Java 8) or:
assertThrows(new Runnable() {
#Override public void run() { methodThatThrows(); }
});
...in Java 6/7. Importantly, assertThrows is called before methodThatThrows, so it can invoke methodThatThrows. Thanks Stefan for pointing out Fishbowl, but you could easily write an equivalent yourself:
public void assertThrows(Runnable block) {
try {
block.run();
fail("Block didn't throw.");
} catch (Exception ex) { }
}
Things that don't work:
#Test(expected=YourException.class) will go up the stack to the try block that JUnit wraps your test method in. Control never returns to the test method after that.
JUnit4's ExpectedException #Rule looks tempting, but because it wraps the entire test method, you have to set expectations before calling the method that throws the exception.
Anything that looks like assertThrows(methodCallThatThrows()). Java will try to get the return value out of methodCallThatThrows before assertThrows is ever invoked, so any try block there can't help.
With Java 8 you can use the Fishbowl library.
#Test
public void testFooThrowsAtFirstAndSecondTime(){
Throwable firstException = exceptionThrownBy(() -> foo());
assertEquals(Exception.class, firstException.getClass());
Throwable secondException = exceptionThrownBy(() -> foo());
assertEquals(Exception.class, secondException.getClass());
foo()
}
It is possible to use this library with Java 6 and 7, too. But then you have to use anonymous classes.
#Test
public void testFooThrowsAtFirstAndSecondTime(){
Throwable firstException = exceptionThrownBy(new Statement() {
public void evaluate() throws Throwable {
foo();
}
});
assertEquals(Exception.class, firstException.getClass());
Throwable secondException = exceptionThrownBy(new Statement() {
public void evaluate() throws Throwable {
foo();
}
});
assertEquals(Exception.class, secondException.getClass());
foo()
}
If you are unlucky enough to have to code for some version of java prior to 8, then you cannot do it with one line per exception.
But if you are using java 8, then you can do it as Stefan Birkner suggested.
Now, if you are unwilling to include an entire library for just one method, then here is a method that will work for you, copied from my blog
public final <T extends Throwable> T expectException( Class<T> exceptionClass, Runnable runnable )
{
try
{
runnable.run();
}
catch( Throwable throwable )
{
if( throwable instanceof AssertionError && throwable.getCause() != null )
throwable = throwable.getCause();
assert exceptionClass.isInstance( throwable ) : throwable; //exception of the wrong kind was thrown.
assert throwable.getClass() == exceptionClass : throwable; //exception thrown was a subclass, but not the exact class, expected.
#SuppressWarnings( "unchecked" )
T result = (T)throwable;
return result;
}
assert false; //expected exception was not thrown.
return null; //to keep the compiler happy.
}
So, your test code becomes something like this:
#Test
public void testFooThrowsAtFirstAndSecondTime()
{
expectException( Exception.class, this::foo );
expectException( Exception.class, this::foo );
foo();
}
#Test(expected=Exception.class)
I have created Exception xml and dynamically create and throw exception.
<exception-mappings>
<exception-mapping key="exceptionkey1">
<class-name>com.package.CheckedException</class-name>
<message>Checked Exception Message</message>
</exception-mapping>
<exception-mapping key="exceptionkey2">
<class-name>com.package.UnCheckedException</class-name>
<message>UnChecked Exception Message</message>
</exception-mapping>
I create object of exception dynamically using reflection depending on the exception key.
public static void throwException(final String key) throws CheckedException, UncheckedException {
ExceptionMapping exceptionMapping = exceptionMappings.getExceptionMappings().get(key);
if (exceptionMapping != null) {
try {
Class exceptionClass = Class.forName(exceptionMapping.getClassName());
try {
throw ()exceptionClass.newInstance(); // line X
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
I want to know which class to typecast at line X so that I do not need to use If/else. Reason behind I do not want to use if else is, it may be possible that in future, there may be new classes added and I do not want to change this code every time new exception is added.
My base logic is my service layer will throw either CheckedException or UncheckedException. If CheckedException is thrown, it will be handled by my web layer. Also I can not throw Super parent class Exception or Throwable as my web layer only catch CheckedException. If UncheckedException is thrown, it will display exception page.
Please help me as I am not able to proceed further.
EDIT: Any other solution is also accepted.
Well, in the name of science, here's how you can do it. Would I recommend doing this? By no means. Would I ever do anything remotely like this myself? Probably not.
public class ExceptionFactory {
public static void throwException(String className)
throws CheckedException, UncheckedException {
Class<?> exceptionClass;
try {
exceptionClass = Class.forName(className);
} catch (ClassNotFoundException e) {
throw new IllegalArgumentException(e);
}
try {
if (CheckedException.class.isAssignableFrom(exceptionClass)) {
throw exceptionClass.asSubclass(CheckedException.class)
.newInstance();
} else if (UncheckedException.class
.isAssignableFrom(exceptionClass)) {
throw exceptionClass.asSubclass(UncheckedException.class)
.newInstance();
} else {
throw new IllegalArgumentException(
"Not a valid exception type: "
+ exceptionClass.getName());
}
} catch (InstantiationException | IllegalAccessException e) {
throw new IllegalStateException(e);
}
}
public static void main(String... args) {
try {
throwException("CheckedException");
} catch (CheckedException e) {
System.out.println(e);
} catch (UncheckedException e) {
System.out.println(e);
}
}
}
class CheckedException extends Exception {
}
class UncheckedException extends Exception {
}
I don't see the point of this factory. Even if you get it to work (which you can by having all the exceptions thrown by it being sub-classes of a single ancestor class), its usage would be something like this :
....
if (somethingInWrong) {
ExceptionFactory.throwException("SomeKey");
}
....
For each key you'd still have to create an exception class to be mapped to it. Lets say SomeKeyException is the exception mapped to "SomeKey".
In that case, it's much more type safe to simply write :
....
if (somethingInWrong) {
throw new SomeKeyException();
}
....
This way the compiler checks that you are creating an exception class that it actually knows. If you use your Factory, you might use some String that is not a valid key, and the compiler won't be able to do anything about it. Only in runtime your Factory will fail to find an exception mapped to the invalid key.
There's no need to use reflection (as I commented above you shouldn't use reflection unless you really have to...).
You can implement the exceptions class to be something like this:
class MyExceptions {
static void myExceptionsThrower(String key) throws Exception {
if("illegalstate".equals(key)) {
throw new IllegalStateException("that's my IllegalStateException bro!");
}
else if("illegalaccess".equals(key)) {
throw new IllegalAccessException("that's my IllegalAccessException bro!");
}
// etc...
}
}
and use it with:
MyExceptions.myExceptionsThrower(key);
A few tweaks:
public static void throwException(final String key) throws Throwable {
ExceptionMapping exceptionMapping =
exceptionMappings.getExceptionMappings().get(key);
if (exceptionMapping != null) {
try {
Class<Throwable> exceptionClass =
(Class<Throwable>)Class.forName(exceptionMapping.getClassName());
try {
throw exceptionClass.cast( exceptionClass.newInstance() ); // line X
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
Here's my entry into this derby. :-)
The other answers have commented on whether this is a reasonable design. I'll set these issues aside for the purpose of this answer.
A couple of my pet peeves are unnecessary warnings (even if suppressed), and exceptions that don't report what actually went wrong. In particular merely printing out a stack trace is usually insufficient. Yes, this is just test code, but when dealing with code like this -- even code that's designed to throw an exception -- one really ought to think about how to deal with errors. In this case I've chosen to represent these kinds of errors as instances of InternalError since the configuration or whatever can be wrong in a variety of ways. Specifically: if the class can't be found, if it is found but isn't a subtype of CheckedException or UncheckedException (or even an ordinary class), or if doesn't have a no-arg constructor or if it's inaccessible.
Another issue with some of the proposed solutions is that if the exception class name is "java.lang.InstantiationException" (or one of the other internally-caught exceptions) an instance of this exception type might be constructed, thrown, and then caught internally, resulting in a stack trace but not actually throwing the requested exception. I've avoided that by linearizing the logic instead of nesting try-catch blocks.
Finally, I extracted the exception-creating code into a separate method so that it can be used for both the checked and unchecked cases. This can be simplified considerably if you rearrange the exception hierarchy to allow only a single root exception (I recommend unchecked) and have exception subtypes that are handled at the web layer or are thrown out to the caller.
static void throwException(final String exClassName) throws CheckedException, UncheckedException {
Class<?> clazz;
try {
clazz = Class.forName(exClassName);
} catch (ClassNotFoundException cnfe) {
throw new InternalError(exClassName, cnfe);
}
if (CheckedException.class.isAssignableFrom(clazz)) {
throw newException(clazz.asSubclass(CheckedException.class));
} else if (UncheckedException.class.isAssignableFrom(clazz)) {
throw newException(clazz.asSubclass(UncheckedException.class));
} else {
throw new InternalError(exClassName + " is not a valid exception");
}
}
static <X extends Throwable> X newException(Class<X> clazz) {
X x;
try {
x = clazz.newInstance();
} catch (InstantiationException|IllegalAccessException e) {
throw new InternalError("creating instance of " + clazz, e);
}
return x;
}
This could be helpful to create a custom precondition exception to avoid multiple if conditions.
Creates a precondition exception while checking for null pointer.
class Preconditions {
/**
* <p>
* Checks the value to be null and if null throws a new Exception with the message given.
* Used to reduce checking if conditions for complexity.
* </p>
* #param val - val to check null
* #param exceptionClass - exception class to be thrown
* #param args - message to be called for throwing exception
* #throws Throwable - Common Throwable Exception.
*/
public static void checkNotNull(final Object val, final Class<?> exceptionClass, final Object ...args) throws Throwable {
Class<?>[] argTypes = new Class<?>[args.length];
Arrays.stream(args).map(WithIndex.indexed()).forEach(arg ->argTypes[arg.index()] = arg.value().getClass());
if (null == val) throw (Throwable) exceptionClass.getConstructor(argTypes).newInstance(args);
}
}
Then you can use it in code with:
PreConditionUtil.checkNotNull(objectToCheck, CustomException.class, ErrorCode, "your error message", ...);
I have a test that expects a particular exception, for example:
#Test(expected=MyException.class)
public void testMyMethod(){
myMethod();
}
The myMethod() method actually throws a subclass of MyException, lets call it MySubclassException.
Is there anyway to define my test using the #Test annotation to accept subclasses of MyException as well as the class itself?
I know that I could simply write the test checking logic myself without using expected by catching the exception and setting a flag, but I was wondering whether or not JUnit already supported matching exception subclasses.
This is already handled for you by the framework
Let's take a small example (very bad code):
import static org.junit.Assert.*;
import org.junit.Test;
public class TestExpect {
#Test(expected=MyException.class)
public void test() throws MyException {
new Foo().foo();
}
}
With 2 exception classes MyException and MyExtendedException inheriting from the previous one and a simple Foo class like this one:
public class Foo {
public void foo() throws MyException{
throw new MyExtendedException();
}
}
Launching the test using the Eclipse runner prints a green bar because the test raises one instance of Myexception (is a relationship in POO)
If you prefer to read source code this is an exxcerpt from the Junit source code (ExpectException.java):
#Override
public void evaluate() throws Exception {
boolean complete = false;
try {
fNext.evaluate();
complete = true;
} catch (AssumptionViolatedException e) {
throw e;
} catch (Throwable e) {
if (!fExpected.isAssignableFrom(e.getClass())) {
String message= "Unexpected exception, expected<"
+ fExpected.getName() + "> but was<"
+ e.getClass().getName() + ">";
throw new Exception(message, e);
}
}
if (complete)
throw new AssertionError("Expected exception: "
+ fExpected.getName());
}
The test will pass if MyException or MySubclassException is thrown by myMethod(). I tested the concept with this code:
public class ExceptionTest {
private static class ExceptionA extends Exception {
}
private static class ExceptionB extends ExceptionA {
}
#Test(expected=ExceptionA.class)
public void test() throws Exception {
throw new ExceptionB();
}
}
BDD Style Solution with Catch Exception
#Test
public void testMyMethod() {
when(foo).myMethod();
then(caughtException()).isInstanceOf(MyException.class);
}
Dependencies
com.googlecode.catch-exception:catch-exception:1.2.0