assertDoesNotThrow in JUnit - Framework Patterns

Framework Mode - assertDoesNotThrow

Folder Structure

src/
└── test/
    └── java/
        └── com/
            └── example/
                ├── pages/
                │   └── LoginPage.java
                ├── tests/
                │   └── LoginTests.java
                ├── utils/
                │   └── TestUtils.java
                └── config/
                    └── TestConfig.java

Test Framework Layers

• Config Layer: Holds environment settings, browser configs, credentials (e.g., TestConfig.java).
• Page Object Layer: Represents UI pages with methods to interact (e.g., LoginPage.java).
• Test Layer: Contains test classes with test methods using JUnit assertions like assertDoesNotThrow (e.g., LoginTests.java).
• Utility Layer: Helper methods and reusable code (e.g., TestUtils.java).

Configuration Patterns

• Environment Properties: Use TestConfig.java to load environment variables (dev, test, prod) via System.getProperty or config files.
• Browser Setup: Configure WebDriver in setup methods, selecting browser type from config.
• Credentials Management: Store sensitive data securely, inject into tests via config or environment variables.
• Timeouts and Waits: Centralize timeout values in config for consistency.

Test Reporting and CI/CD Integration

• JUnit Reports: Use built-in JUnit XML reports for test results.
• Enhanced Reporting: Integrate with tools like Allure or Surefire for detailed reports.
• CI/CD Integration: Run tests automatically on code push using Jenkins, GitHub Actions, or GitLab CI.
  • Fail build if assertDoesNotThrow detects an exception.
  • Publish reports as build artifacts.

Best Practices

1. Use assertDoesNotThrow to confirm code runs without exceptions. It makes tests clear and focused on error absence.
2. Keep tests small and focused. Test one behavior per test method.
3. Use Page Object Model. Separate UI logic from tests for easier maintenance.
4. Centralize configuration. Avoid hardcoding values inside tests.
5. Integrate tests into CI/CD. Catch failures early and keep feedback fast.

Self Check

Where would you add a new test method that uses assertDoesNotThrow to verify login functionality?

Key Result

Organize JUnit tests with clear layers and use assertDoesNotThrow to verify no exceptions occur during execution.

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 check that a block of code runs without throwing any exceptions

C. To verify that a specific exception is thrown by the code

D. To measure the execution time of a code block

Solution

1. Step 1: Understand the purpose of assertDoesNotThrow

   This assertion is designed to confirm that no exceptions occur when running a code block.

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 B

4. Quick Check:

   assertDoesNotThrow means no exceptions thrown [OK]

Hint: Remember: assertDoesNotThrow means code runs without errors [OK]

Common Mistakes:

• Confusing assertDoesNotThrow with assertThrows
• Thinking it checks return values
• Assuming it measures performance

2. Which of the following is the correct syntax to use assertDoesNotThrow in JUnit 5?

easy

A. assertDoesNotThrow(methodToTest());

B. assertDoesNotThrow { methodToTest() };

C. assertDoesNotThrow(() -> methodToTest());

D. assertDoesNotThrow(methodToTest);

Solution

1. Step 1: Recall the lambda syntax for assertDoesNotThrow

   assertDoesNotThrow expects a lambda expression or executable block, written as () -> methodToTest().

2. Step 2: Identify incorrect options

   Options A, C, and D use incorrect syntax: A calls the method directly, C uses braces like other languages, D passes method reference without lambda.

3. Final Answer:

   assertDoesNotThrow(() -> methodToTest()); -> Option C

4. Quick Check:

   Use lambda () -> method() with assertDoesNotThrow [OK]

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

Common Mistakes:

• Calling the method directly inside assertDoesNotThrow
• Using curly braces instead of lambda arrows
• Passing method name without parentheses or lambda

3. What will be the result of this JUnit test?

assertDoesNotThrow(() -> { int x = 5 / 1; });

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 5 by 1, which is valid and does not throw any exception.

2. Step 2: Understand assertDoesNotThrow behavior

   Since no exception occurs, the assertion passes and the test succeeds.

3. Final Answer:

   Test passes because no exception is thrown -> Option D

4. Quick Check:

   Division by 1 is safe, so no exception [OK]

Hint: Check if code inside lambda throws exception or not [OK]

Common Mistakes:

• Assuming division always throws exception
• Confusing ArithmeticException with other exceptions
• Thinking assertDoesNotThrow checks return values

4. Identify the error in this JUnit test using assertDoesNotThrow:

assertDoesNotThrow(() -> { int y = 10 / 0; });

medium

A. ArithmeticException will cause test to fail

B. No error; test will pass

C. Syntax error due to missing semicolon

D. NullPointerException will cause test to fail

Solution

1. Step 1: Examine the code inside assertDoesNotThrow

   The code divides 10 by 0, which causes an ArithmeticException at runtime.

2. Step 2: Understand assertDoesNotThrow behavior on exceptions

   assertDoesNotThrow expects no exceptions; if one occurs, the test fails.

3. Final Answer:

   ArithmeticException will cause test to fail -> Option A

4. Quick Check:

   Division by zero throws ArithmeticException [OK]

Hint: Division by zero throws exception, so test fails [OK]

Common Mistakes:

• Thinking test passes despite exception
• Confusing exception types
• Ignoring runtime exceptions inside lambda

5. You want to test a method processData() that may throw a checked exception. How do you use assertDoesNotThrow to verify it runs without exceptions?

hard

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

B. assertDoesNotThrow(processData());

C. assertDoesNotThrow(() -> { try { processData(); } catch(Exception e) {} });

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

Solution

1. Step 1: Understand handling checked exceptions in lambdas

   assertDoesNotThrow accepts an Executable, whose execute() method throws Throwable, so checked exceptions are permitted in the lambda.

2. Step 2: Identify the correct lambda syntax

   The standard syntax is a concise lambda: () -> processData().

3. Step 3: Evaluate options

   A: correct single-expression lambda. B: direct method call without lambda. C: catches exceptions inside lambda, hiding potential failures. D: syntax error due to missing semicolon after processData() in the block lambda.

4. Final Answer:

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

5. Quick Check:

   Lambda () -> processData() handles checked exceptions correctly [OK]

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

Common Mistakes:

• Calling method directly without lambda
• Syntax errors like missing semicolon in block lambdas
• Catching exceptions inside lambda hiding test failures