Testing no exception thrown in JUnit - Build an Automation Script

Verify method completes without throwing any exception

Preconditions (2)

Step 1: Call the method 'processData' with input 'validInput'

Step 2: Observe if any exception is thrown during the method call

✅ Expected Result: The method 'processData' completes execution without throwing any exception

Automation Requirements - JUnit 5

Assertions Needed:

Verify that no exception is thrown when calling 'processData' with 'validInput'

Best Practices:

Use assertDoesNotThrow to check no exception is thrown

Keep test method names descriptive

Isolate the test to only check exception behavior

Automated Solution

JUnit

import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import org.junit.jupiter.api.Test;

public class DataProcessorTest {

    @Test
    void processData_shouldNotThrowException_whenValidInput() {
        DataProcessor processor = new DataProcessor();
        assertDoesNotThrow(() -> processor.processData("validInput"));
    }
}

class DataProcessor {
    public void processData(String input) {
        // Simulate processing
        if (input == null) {
            throw new IllegalArgumentException("Input cannot be null");
        }
        // Processing logic here
    }
}

The test class DataProcessorTest uses JUnit 5.

The test method processData_shouldNotThrowException_whenValidInput clearly states what it tests.

Inside the test, we create an instance of DataProcessor and call processData with a valid string.

We use assertDoesNotThrow to verify that no exception is thrown during the call.

This method is the best practice to check that a method runs without exceptions in JUnit 5.

The DataProcessor class is included for completeness, showing a simple method that throws an exception only if input is null.

Common Mistakes - 3 Pitfalls

{'mistake': 'Using try-catch block inside test instead of assertDoesNotThrow', 'why_bad': 'It makes the test code longer and less readable, and may miss assertion failures if exceptions are swallowed.', 'correct_approach': "Use JUnit 5's assertDoesNotThrow to clearly express the intent and keep test concise."}

Not testing with valid input and assuming no exception

Using JUnit 4 style expected exception annotation for no exception scenario

Bonus Challenge

Now add data-driven testing with 3 different valid inputs to verify no exception is thrown for each

Show Hint

Practice

1. What is the main purpose of assertDoesNotThrow in JUnit testing?

easy

A. To assert that a method returns a specific value

B. To verify that a specific exception is thrown

C. To check that a block of code runs without throwing any exceptions

D. To test if a method runs within a time limit

Solution

1. Step 1: Understand the purpose of assertDoesNotThrow

   This assertion is used to confirm that no exceptions occur when running a piece of code.

2. Step 2: Compare with other assertions

   Unlike assertions that check for exceptions or return values, assertDoesNotThrow ensures smooth execution without errors.

3. Final Answer:

   To check that a block of code runs without throwing any exceptions -> Option C

4. Quick Check:

   assertDoesNotThrow = no exceptions thrown [OK]

Hint: Remember: assertDoesNotThrow means code runs error-free [OK]

Common Mistakes:

• Confusing assertDoesNotThrow with assertThrows
• Thinking it checks return values
• Assuming it tests performance or timing

2. Which of the following is the correct syntax to test that no exception is thrown by myMethod() using JUnit 5?

easy

A. assertDoesNotThrow(() -> myMethod());

B. assertThrows(() -> myMethod());

C. assertNoException(myMethod());

D. assertDoesNotThrow(myMethod);

Solution

1. Step 1: Recall the correct method signature

   In JUnit 5, assertDoesNotThrow takes a lambda expression or executable block, like () -> myMethod().

2. Step 2: Identify correct syntax

   assertDoesNotThrow(() -> myMethod()); correctly uses a lambda expression. assertThrows(() -> myMethod()); tests for exceptions, non-existent methods like assertNoException(myMethod()); won't work, and assertDoesNotThrow(myMethod); misses lambda syntax.

3. Final Answer:

   assertDoesNotThrow(() -> myMethod()); -> Option A

4. Quick Check:

   Use lambda with assertDoesNotThrow [OK]

Hint: Use lambda syntax () -> method() inside assertDoesNotThrow [OK]

Common Mistakes:

• Using assertThrows instead of assertDoesNotThrow
• Passing method reference without lambda
• Using non-existent assertion methods

3. Consider the following JUnit test code:

assertDoesNotThrow(() -> {
    int result = 10 / 2;
    System.out.println(result);
});

What will be the test result when this test runs?

medium

A. Test fails due to syntax error

B. Test fails due to ArithmeticException

C. Test fails due to NullPointerException

D. Test passes because no exception is thrown

Solution

1. Step 1: Analyze the code inside assertDoesNotThrow

   The code divides 10 by 2, which is valid and does not cause exceptions.

2. Step 2: Determine test outcome

   Since no exception occurs, assertDoesNotThrow passes the test.

3. Final Answer:

   Test passes because no exception is thrown -> Option D

4. Quick Check:

   No exception means test passes [OK]

Hint: Check if code inside lambda can throw exceptions [OK]

Common Mistakes:

• Assuming division always throws exception
• Confusing print statements with exceptions
• Thinking syntax error occurs without cause

4. Identify the error in this JUnit 5 test code that aims to check no exception is thrown:

@Test
void testSafeMethod() {
    assertDoesNotThrow(mySafeMethod());
}

void mySafeMethod() {
    // safe code
}

medium

A. Method mySafeMethod is not annotated with @Test

B. Missing lambda expression; method is called immediately instead of passed

C. assertDoesNotThrow cannot be used with void methods

D. Test method must return a value

Solution

1. Step 1: Check how assertDoesNotThrow is called

   The code calls mySafeMethod() immediately and passes its result, which is void, instead of passing a lambda.

2. Step 2: Correct usage of assertDoesNotThrow

   It requires a lambda like () -> mySafeMethod() to defer execution and catch exceptions.

3. Final Answer:

   Missing lambda expression; method is called immediately instead of passed -> Option B

4. Quick Check:

   Pass lambda, not method call, to assertDoesNotThrow [OK]

Hint: Always wrap method call in lambda for assertDoesNotThrow [OK]

Common Mistakes:

• Calling method instead of passing lambda
• Thinking void methods can't be tested
• Ignoring lambda syntax requirement

5. You want to test that a method processData(String input) does not throw exceptions for any non-null input. Which JUnit 5 test code correctly tests this for inputs "hello" and "world" using assertDoesNotThrow?

hard

A. assertDoesNotThrow(() -> {
processData("hello");
processData("world");
});

B. assertDoesNotThrow(processData("hello"));
assertDoesNotThrow(processData("world"));

C. assertDoesNotThrow(() -> processData("hello", "world"));

D. assertDoesNotThrow(() -> {
processData(null);
});

Solution

1. Step 1: Understand the requirement

   We want to test that processData does not throw exceptions for both inputs "hello" and "world".

2. Step 2: Check which code tests both inputs in one assertion

   assertDoesNotThrow(() -> { processData("hello"); processData("world"); }); runs both calls inside one lambda passed to assertDoesNotThrow, ensuring both run without exceptions.

3. Step 3: Analyze other options

   The two separate assertDoesNotThrow(processData(...)) calls execute methods immediately without lambdas, which is incorrect. assertDoesNotThrow(() -> processData("hello", "world")); passes two arguments to a one-argument method. assertDoesNotThrow(() -> { processData(null); }); tests null input, which is not required.

4. Final Answer:

   assertDoesNotThrow(() -> { processData("hello"); processData("world"); }); -> Option A

5. Quick Check:

   Group calls in one lambda for multiple inputs [OK]

Hint: Put multiple calls inside one lambda for combined assertDoesNotThrow [OK]

Common Mistakes:

• Passing wrong number of arguments
• Testing null input when not required
• Forgetting lambda expressions