We Keep Coding

How to verify in Mockito if the entity class setter is not called [duplicate]

I know that one way to do it would be:
#Test
public void foo() {
try {
// execute code that you expect not to throw Exceptions.
} catch(Exception e) {
fail("Should not have thrown any exception");
}
}
Is there any cleaner way of doing this? (Probably using Junit's #Rule?)

You're approaching this the wrong way. Just test your functionality: if an exception is thrown the test will automatically fail. If no exception is thrown, your tests will all turn up green.
I have noticed this question garners interest from time to time so I'll expand a little.
Background to unit testing
When you're unit testing it's important to define to yourself what you consider a unit of work. Basically: an extraction of your codebase that may or may not include multiple methods or classes that represents a single piece of functionality.
Or, as defined in The art of Unit Testing, 2nd Edition by Roy Osherove, page 11:
A unit test is an automated piece of code that invokes the unit of work being tested, and then checks some assumptions about a single end result of that unit. A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It's trustworthy, readable, and maintainable. It's consistent in its results as long as production code hasn't changed.
What is important to realize is that one unit of work usually isn't just one method but at the very basic level it is one method and after that it is encapsulated by other unit of works.
Ideally you should have a test method for each separate unit of work so you can always immediately view where things are going wrong. In this example there is a basic method called getUserById() which will return a user and there is a total of 3 unit of works.
The first unit of work should test whether or not a valid user is being returned in the case of valid and invalid input.
Any exceptions that are being thrown by the datasource have to be handled here: if no user is present there should be a test that demonstrates that an exception is thrown when the user can't be found. A sample of this could be the IllegalArgumentException which is caught with the #Test(expected = IllegalArgumentException.class) annotation.
Once you have handled all your usecases for this basic unit of work, you move up a level. Here you do exactly the same, but you only handle the exceptions that come from the level right below the current one. This keeps your testing code well structured and allows you to quickly run through the architecture to find where things go wrong, instead of having to hop all over the place.
Handling a tests' valid and faulty input
At this point it should be clear how we're going to handle these exceptions. There are 2 types of input: valid input and faulty input (the input is valid in the strict sense, but it's not correct).
When you work with valid input you're setting the implicit expectancy that whatever test you write, will work.
Such a method call can look like this: existingUserById_ShouldReturn_UserObject. If this method fails (e.g.: an exception is thrown) then you know something went wrong and you can start digging.
By adding another test (nonExistingUserById_ShouldThrow_IllegalArgumentException) that uses the faulty input and expects an exception you can see whether your method does what it is supposed to do with wrong input.
TL;DR
You were trying to do two things in your test: check for valid and faulty input. By splitting this into two method that each do one thing, you will have much clearer tests and a much better overview of where things go wrong.
By keeping the layered unit of works in mind you can also reduce the amount of tests you need for a layer that is higher in the hierarchy because you don't have to account for every thing that might have gone wrong in the lower layers: the layers below the current one are a virtual guarantee that your dependencies work and if something goes wrong, it's in your current layer (assuming the lower layers don't throw any errors themselves).

JUnit 5 (Jupiter) provides three functions to check exception absence/presence:
● assertAll​()
  Asserts that all supplied executables
  do not throw exceptions.
● assertDoesNotThrow​()
  Asserts that execution of the
  supplied executable/supplier
  does not throw any kind of exception.
  This function is available
  since JUnit 5.2.0 (29 April 2018).
● assertThrows​()
  Asserts that execution of the supplied executable
  throws an exception of the expectedType
  and returns the exception.
Example
package test.mycompany.myapp.mymodule;
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
class MyClassTest {
#Test
void when_string_has_been_constructed_then_myFunction_does_not_throw() {
String myString = "this string has been constructed";
assertAll(() -> MyClass.myFunction(myString));
}
#Test
void when_string_has_been_constructed_then_myFunction_does_not_throw__junit_v520() {
String myString = "this string has been constructed";
assertDoesNotThrow(() -> MyClass.myFunction(myString));
}
#Test
void when_string_is_null_then_myFunction_throws_IllegalArgumentException() {
String myString = null;
assertThrows(
IllegalArgumentException.class,
() -> MyClass.myFunction(myString));
}
}

I stumbled upon this because of SonarQube's rule "squid:S2699": "Add at least one assertion to this test case."
I had a simple test whose only goal was to go through without throwing exceptions.
Consider this simple code:
public class Printer {
public static void printLine(final String line) {
System.out.println(line);
}
}
What kind of assertion can be added to test this method?
Sure, you can make a try-catch around it, but that is only code bloat.
The solution comes from JUnit itself.
In case no exception is thrown and you want to explicitly illustrate this behaviour, simply add expected as in the following example:
#Test(expected = Test.None.class /* no exception expected */)
public void test_printLine() {
Printer.printLine("line");
}
Test.None.class is the default for the expected value.
If you import org.junit.Test.None, you can then write:
#Test(expected = None.class)
which you might find more readable.

For JUnit versions before 5:
With AssertJ fluent assertions 3.7.0:
Assertions.assertThatCode(() -> toTest.method())
.doesNotThrowAnyException();
Update:
JUnit 5 introduced assertDoesNotThrow() assertion, so I'd prefer to use it instead of adding an additional dependency to your project. See this answer for details.

Java 8 makes this a lot easier, and Kotlin/Scala doubly so.
We can write a little utility class
class MyAssertions{
public static void assertDoesNotThrow(FailingRunnable action){
try{
action.run()
}
catch(Exception ex){
throw new Error("expected action not to throw, but it did!", ex)
}
}
}
#FunctionalInterface interface FailingRunnable { void run() throws Exception }
and then your code becomes simply:
#Test
public void foo(){
MyAssertions.assertDoesNotThrow(() -> {
//execute code that you expect not to throw Exceptions.
}
}
If you dont have access to Java-8, I would use a painfully old java facility: aribitrary code blocks and a simple comment
//setup
Component component = new Component();
//act
configure(component);
//assert
/*assert does not throw*/{
component.doSomething();
}
And finally, with kotlin, a language I've recently fallen in love with:
fun (() -> Any?).shouldNotThrow()
= try { invoke() } catch (ex : Exception){ throw Error("expected not to throw!", ex) }
#Test fun `when foo happens should not throw`(){
//...
{ /*code that shouldn't throw*/ }.shouldNotThrow()
}
Though there is a lot of room to fiddle with exactly how you want to express this, I was always a fan of fluent assertions.
Regarding
You're approaching this the wrong way. Just test your functionality: if an exception is thrown the test will automatically fail. If no exception is thrown, your tests will all turn up green.
This is correct in principle but incorrect in conclusion.
Java allows exceptions for flow of control. This is done by the JRE runtime itself in APIs like Double.parseDouble via a NumberFormatException and Paths.get via a InvalidPathException.
Given you've written a component that validates Number strings for Double.ParseDouble, maybe using a Regex, maybe a hand-written parser, or perhaps something that embeds some other domain rules that restricts the range of a double to something specific, how best to test this component? I think an obvious test would be to assert that, when the resulting string is parsed, no exception is thrown. I would write that test using either the above assertDoesNotThrow or /*comment*/{code} block. Something like
#Test public void given_validator_accepts_string_result_should_be_interpretable_by_doubleParseDouble(){
//setup
String input = "12.34E+26" //a string double with domain significance
//act
boolean isValid = component.validate(input)
//assert -- using the library 'assertJ', my personal favourite
assertThat(isValid).describedAs(input + " was considered valid by component").isTrue();
assertDoesNotThrow(() -> Double.parseDouble(input));
}
I would also encourage you to parameterize this test on input using Theories or Parameterized so that you can more easily re-use this test for other inputs. Alternatively, if you want to go exotic, you could go for a test-generation tool (and this). TestNG has better support for parameterized tests.
What I find particularly disagreeable is the recommendation of using #Test(expectedException=IllegalArgumentException.class), this exception is dangerously broad. If your code changes such that the component under test's constructor has if(constructorArgument <= 0) throw IllegalArgumentException(), and your test was supplying 0 for that argument because it was convenient --and this is very common, because good generating test data is a surprisingly hard problem--, then your test will be green-bar even though it tests nothing. Such a test is worse than useless.

If you are unlucky enough to catch all errors in your code.
You can stupidly do
class DumpTest {
Exception ex;
#Test
public void testWhatEver() {
try {
thisShouldThrowError();
} catch (Exception e) {
ex = e;
}
assertEquals(null,ex);
}
}

Although this post is 6 years old now, however, a lot has changed in the Junit world. With Junit5, you can now use
org.junit.jupiter.api.Assertions.assertDoesNotThrow()
Ex:
public void thisMethodDoesNotThrowException(){
System.out.println("Hello There");
}
#Test
public void test_thisMethodDoesNotThrowException(){
org.junit.jupiter.api.Assertions.assertDoesNotThrow(
()-> thisMethodDoesNotThrowException()
);
}
Hope it will help people who are using newer version of Junit5

JUnit5 adds the assertAll() method for this exact purpose.
assertAll( () -> foo() )
source: JUnit 5 API

To test a scenario with a void method like
void testMeWell() throws SomeException {..}
to not throw an exception:
Junit5
assertDoesNotThrow(() -> {
testMeWell();
});

If you want to test that whether your test target consumes the exception. Just leave the test as (mock collaborator using jMock2):
#Test
public void consumesAndLogsExceptions() throws Exception {
context.checking(new Expectations() {
{
oneOf(collaborator).doSth();
will(throwException(new NullPointerException()));
}
});
target.doSth();
}
The test would pass if your target does consume the exception thrown, otherwise the test would fail.
If you want to test your exception consumption logic, things get more complex. I suggest delegating the consumption to a collaborator which could be mocked. Therefore the test could be:
#Test
public void consumesAndLogsExceptions() throws Exception {
Exception e = new NullPointerException();
context.checking(new Expectations() {
{
allowing(collaborator).doSth();
will(throwException(e));
oneOf(consumer).consume(e);
}
});
target.doSth();
}
But sometimes it's over-designed if you just want to log it. In this case, this article(http://java.dzone.com/articles/monitoring-declarative-transac, http://blog.novoj.net/2008/09/20/testing-aspect-pointcuts-is-there-an-easy-way/) may help if you insist tdd in this case.

Use assertNull(...)
#Test
public void foo() {
try {
//execute code that you expect not to throw Exceptions.
} catch (Exception e){
assertNull(e);
}
}

This may not be the best way but it definitely makes sure that exception is not thrown from the code block that is being tested.
import org.assertj.core.api.Assertions;
import org.junit.Test;
public class AssertionExample {
#Test
public void testNoException(){
assertNoException();
}
private void assertException(){
Assertions.assertThatThrownBy(this::doNotThrowException).isInstanceOf(Exception.class);
}
private void assertNoException(){
Assertions.assertThatThrownBy(() -> assertException()).isInstanceOf(AssertionError.class);
}
private void doNotThrowException(){
//This method will never throw exception
}
}

I faced the same situation, I needed to check that exception is thrown when it should, and only when it should.
Ended up using the exception handler to my benefit with the following code:
try {
functionThatMightThrowException()
}catch (Exception e){
Assert.fail("should not throw exception");
}
RestOfAssertions();
The main benefit for me was that it is quite straight forward and to check the other way of the "if and only if" is really easy in this same structure

I end up doing like this
#Test
fun `Should not throw`() {
whenever(authService.isAdmin()).thenReturn(true)
assertDoesNotThrow {
service.throwIfNotAllowed("client")
}
}

You can expect that exception is not thrown by creating a rule.
#Rule
public ExpectedException expectedException = ExpectedException.none();

You can do it by using a #Rule and then call method reportMissingExceptionWithMessage as shown below:
This is Scala code.

Stumbled over this issue since I created some generic methods like
#Test
void testSomething() {
checkGeneric(anComplexObect)
}
In https://newbedev.com/sonarqube-issue-add-at-least-one-assertion-to-this-test-case-for-unit-test-with-assertions some annotation stuff is proposed.
The solution is much more simple. It's enough to rename the "checkGeneric" method to "assertGeneric".
#Test
void testSomething() {
assertGeneric(anComplexObect)
}

You can create any kind of your own assertions based on assertions from junit, because these are especially designed for creating user defined asserts intendet to work exactly like junit ones:
static void assertDoesNotThrow(Executable executable) {
assertDoesNotThrow(executable, "must not throw");
}
static void assertDoesNotThrow(Executable executable, String message) {
try {
executable.execute();
} catch (Throwable err) {
fail(message);
}
}
Now testing the so called scenario methodMustNotThrow and log all failures in a junit style:
//test and log with default and custom messages
//the following will succeed
assertDoesNotThrow(()->methodMustNotThrow(1));
assertDoesNotThrow(()->methodMustNotThrow(1), "custom facepalm");
//the following will fail
assertDoesNotThrow(()->methodMustNotThrow(2));
assertDoesNotThrow(()-> {throw new Exception("Hello world");}, "message");
//See implementation of methodMustNotThrow below
Generally speaking there is possibility to instantly fail anything the test in any scenarios, in any place where it makes sense by calling fail(someMessage), which is designed exactly for this purpose. For instance use it in a try/catch block to fail if anything is thrown in the test case:
try{methodMustNotThrow(1);}catch(Throwable e){fail("must not throw");}
try{methodMustNotThrow(1);}catch(Throwable e){Assertions.fail("must not throw");}
This is the sample of the method we test, supposing we have such a method that must not fail under specific circumstances, but it can fail:
void methodMustNotThrow(int x) throws Exception {
if (x == 1) return;
throw new Exception();
}
The above method is a simple sample. But this works for complex situations, where the failure is not so obvious.
There are the imports:
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.function.Executable;
import static org.junit.jupiter.api.Assertions.*;

AssertJ can handle this scenario:
assertThatNoException().isThrownBy(() -> System.out.println("OK"));
Check the doc for more information https://assertj.github.io/doc/#assertj-core-exception-assertions-no-exception

The following fails the test for all exceptions, checked or unchecked:
#Test
public void testMyCode() {
try {
runMyTestCode();
} catch (Throwable t) {
throw new Error("fail!");
}
}

How should a unit test deal with expected and unexpected exceptions?

Should it pass the test when the expected exception takes place?
Should it fail the test when an unexpected exception arises?
Is it redundant to handle the exception since it'll fail the test and therefore act as a test?

Test Expected Exceptions
You have to add the expected attribute with the expected exception, so the test will pass if the specified exception is thrown. Otherwise, it will fail.
For example:
#Test(expected=NullPointerException.class)
public void cannotConvertNulls() {
service.convert(null);
}
or...
#Test(expected = ArithmeticException.class)
public void divisionWithException() {
int i = 1/0;
}
Documentation says:
The Test annotation supports two optional parameters. The first,
expected, declares that a test method should throw an exception. If it
doesn't throw an exception or if it throws a different exception than
the one declared, the test fails.
Test Timemouts
Just to let you know, you can also test timeouts.
The second optional parameter, timeout, causes a test to fail if it
takes longer than a specified amount of clock time (measured in
milliseconds). The following test fails:
#Test(timeout=100)
public void infinity() {
while(true);
}
Hope to help

For expected exceptions there are really nice ways to do this with JUnit:
#Test(expected=NullPointerException.class)
public void testNullPointerExceptionIsThrown() {
ArrayList emptyList;
emptyList.size(); //or add, remove etc.
}
The above test in JUnit would pass because it was declared with the #Test annotation that the test method should expect that a null pointer exception is thrown.

If the test is to expect a particular exception will arise with certain data, then yes, it should pass if that particular exception is thrown.
If the test is to expect a particular exception will arise with certain data, or there is no expectation of an exception, then yes, it should fail if any exception outside of expected is thrown.
Do not handle the thrown exceptions yourself unless you have to (and if you have to, that's a test smell - revisit why you're handling exceptions). The best way to indicate to JUnit that you expect an exception is to use the expected field on the #Test annotation.
For example, let's say you were testing a Roman numeral converter, and said that anything not in the normal Roman numerals was an illegal argument (namely, P).
#Test(expected = IllegalArgumentException.class)
public void method_takesIllegalArgument_throwsIllegalArgumentException() {
convertRomanNumeralToNumber("PXL");
}

Exceptions are part of your API, and sometimes explicitly so. As such, you should document the exceptions that your code may throw, and write tests to ensure that they are upheld.
#Test(expected = ThisException.class) is an excellent place to start, if you have JUnit4 and are writing a method that will throw new ThisException(...). Note the value here of picking the most appropriate exception: If you get lazy and use expected = Exception.class, your code would accept it if you change to throw new ThatException(...) instead. Your non-exception code should pass if and only if no exceptions are thrown (which JUnit will enforce for you), and your tests should carefully specify exactly which exception to expect so they can fail if and only if that specific exception is thrown.
As dhiller noted in the comments, the ExpectedException rule is also a very good choice for JUnit4, and allows further inspection of the thrown exception:
#Rule ExpectedException expectedException = ExpectedException.none();
#Test public void yourTest() {
// This is for demonstration. Don't actually verify the exact exception message
// unless you want to have to update your test if the text ever changes.
expectedException.expectMessage("Error 743: Toilet paper missing.");
systemUnderTest.doStuff();
}
But if you really want to check state after catching an exception, the best way to go is JUnit3-style:
#Test public void yourTest() {
try {
systemUnderTest.doStuff();
fail("ThisException expected.");
} catch (ThisException expected) {
assertEquals(743, expected.getErrorNumber());
}
// In both #Test(expected=...) and ExpectedException code, the
// exception-throwing line will be the last executed line, because Java will
// still traverse the call stack until it reaches a try block--which will be
// inside the JUnit framework in those cases. The only way to prevent this
// behavior is to use your own try block.
// This is especially useful to test the state of the system after the
// exception is caught.
assertFalse(systemUnderTest.hasToiletPaper());
}
Another library that claims to help here is catch-exception; however, as of May 2014, the project appears to be in maintenance mode (obsoleted by Java 8), and much like Mockito catch-exception can only manipulate non-final methods.

A test should fail on throwing exception

#Test
public void testA() throws Exception {
}
Is above a good style to code ? Because the test is allowed to throw exceptions and if the code throws exception, then Netbeans consider that as a successful test case.
If yes, then I want to make the test fail if it throws any exception, how can I do that ?

Your code is perfectly valid if you want the test to fail if any exception occurs. Imho this is good style if a checked exception may be thrown in the test code, but should not occur.
If you wish to test exception generation on a specific line or wish to verify something on the exception itself, this pattern is usually more helpful:
#Test
public void testA() {
// Initialize
try {
// Except Exception here
Assert.fail("Exception not thrown");
} catch (IWantToCatchException ex) {
// Assert exception is correct
}
// other code
}

To pass a test when an exception is thrown you need to set the expected element of the Test annotation.
#Test(expected=Exception.class)
Otherwise jUnit will fail the test if an exception is thrown, which may be appropriate in your case.

Since JUnit 4.7 there is the expected part in the annotation of tests:
#Test(expected=YourException.class)
With this the test succeeds only if the exception is thrown.
Therefore, if you leave expected out, the test fails whenever an exception is thrown.

Exceptions are the rare cases which you don't know will happen or not, but you take precautions. But in case of unit testing if you are assured of that it will throw certain exception then test it that way like :
#Test(expected = ArithmeticException.class)
public void testA() {
int i = 1/0;
}

JUnit Testing Exceptions [duplicate]

This question already has answers here:
How do you assert that a certain exception is thrown in JUnit tests?
(35 answers)
Closed 8 years ago.
I'm really new to java.
I'm running some JUnit tests on a constructor. The constructor is such that if it is given a null or an empty string for one of its parameters, it's supposed to throw an exception.
When I test this constructor in JUnit with a null or an empty string parameter, I get a red bar, even though I'm almost 100% sure that the constructor method does indeed throw an exception when such parameters are passed in to it.
Shouldn't there be a green bar in JUnit if the method throws an exception the way it is supposed to? Or is it that when you are supposed to get a red bar when the exception throwing works the way it is supposed to?

#Test(expected = Exception.class)
Tells Junit that exception is the expected result so test will be passed (marked as green) when exception is thrown.
For
#Test
Junit will consider test as failed if exception is thrown, provided it's an unchecked exception. If the exception is checked it won't compile and you will need to use other methods.
This link might help.

are you sure you told it to expect the exception?
for newer junit (>= 4.7), you can use something like (from here)
#Rule
public ExpectedException exception = ExpectedException.none();
#Test
public void testRodneCisloRok(){
exception.expect(IllegalArgumentException.class);
exception.expectMessage("error1");
new RodneCislo("891415",dopocitej("891415"));
}
and for older junit, this:
#Test(expected = ArithmeticException.class)
public void divisionWithException() {
int i = 1/0;
}

If your constructor is similar to this one:
public Example(String example) {
if (example == null) {
throw new NullPointerException();
}
//do fun things with valid example here
}
Then, when you run this JUnit test you will get a green bar:
#Test(expected = NullPointerException.class)
public void constructorShouldThrowNullPointerException() {
Example example = new Example(null);
}

An adventage of use ExpectedException Rule (version 4.7) is that you can test exception message and not only the expected exception.
And using Matchers, you can test the part of message you are interested:
exception.expectMessage(containsString("income: -1000.0"));

Though #Test(expected = MyException.class) and the ExpectedException rule are very good choices, there are some instances where the JUnit3-style exception catching is still the best way to go:
#Test public void yourTest() {
try {
systemUnderTest.doStuff();
fail("MyException expected.");
} catch (MyException expected) {
// Though the ExpectedException rule lets you write matchers about
// exceptions, it is sometimes useful to inspect the object directly.
assertEquals(1301, expected.getMyErrorCode());
}
// In both #Test(expected=...) and ExpectedException code, the
// exception-throwing line will be the last executed line, because Java will
// still traverse the call stack until it reaches a try block--which will be
// inside the JUnit framework in those cases. The only way to prevent this
// behavior is to use your own try block.
// This is especially useful to test the state of the system after the
// exception is caught.
assertTrue(systemUnderTest.isInErrorState());
}
Another library that claims to help here is catch-exception; however, as of May 2014, the project appears to be in maintenance mode (obsoleted by Java 8), and much like Mockito catch-exception can only manipulate non-final methods.

Why does CodePro junit test methods throw Exception (in Eclipse)?

Eclipse's CodePro generates JUnit tests, however, all test methods that it generates throw Exception even if it is impossible for a checked exception to be thrown. Is this a limitation of CodePro, or a good JUnit practice I haven't seen before?
For example:
#Test
public void testCategory_1()
throws Exception {
String categoryName = "";
Category result = new Category(categoryName);
// add additional test code here
assertNotNull(result);
assertEquals(null, result.getCategoryName());
}
Where new Category(String) and result.getCategoryName() don't throw any checked exceptions.

In the case above, you can remove the throws Exception with no problems. However, in the case where you do have an checked Exception, the code becomes much simpler to manage if you just add the throws Exception. Look at the alternative:
#Test public static void testIt() {
try {
foobar(); // throws an IOException
} catch (Exception e) {
fail("caught an exception " + e.getMessage());
}
}
as opposed to:
#Test public static void testIt() throws IOException {
foobar();
}
JUnit handles Exceptions exactly the same as assertion failures (which is actually implemented as an AssertionError), so if there is an unexpected exception in your code it will result in a failed test, which is probably what you want. And your test is much clearer
If you have an expected exception, then you can either specify it as expectedException in the #Test annotation or using a TestRule ExpectedException.
I use this a lot when I have checked exceptions in my code. It's a lot easier to add throws Exception to your test method rather than a list of all of the checked Exceptions. You do fall foul of some checkstyle rules though :-)
Good practice? Rather acceptable practice. It makes maintenance of tests a lot easier, and the code slightly clearer.

It definitely is not a limitation. When you write a unit test you don't really care what kind of exception is thrown. Outside of expected exceptions, any exception will result in a red bar telling you that something is not OK. Therefore it is sufficient to have a "catch all" throws Exception clause.

You don't have to throw Exception, and I would imaging that tool could have performed the static analysis to determine if a checked exception could have been thrown. However, when I write unit tests by hand I typically add the throw clause because invariably I add a line of code that does throw a checked exception.