Single assertion per test debate in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why do some developers prefer a single assertion per test?

In JUnit testing, some developers argue that each test method should contain only one assertion. What is the main reason for this preference?

A It makes it easier to identify the exact cause of failure when a test fails.

B It reduces the total number of test methods needed in the project.

C It improves the performance of the test suite by running fewer assertions.

D It allows multiple failures to be reported in a single test run.

💡 Hint

Think about how test failures are reported and how debugging is simplified.

Having a single assertion per test helps quickly pinpoint which specific check failed, making debugging easier and faster.

❓ assertion

intermediate

What is the result of this JUnit test with multiple assertions?

Consider the following JUnit test method:

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

public class SampleTest {
    @Test
    void testMultipleAssertions() {
        assertEquals(5, 2 + 3);
        assertEquals(4, 2 * 2);
        assertEquals(6, 2 + 2);
    }
}

What will be the outcome when this test runs?

JUnit

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

public class SampleTest {
    @Test
    void testMultipleAssertions() {
        assertEquals(5, 2 + 3);
        assertEquals(4, 2 * 2);
        assertEquals(6, 2 + 2);
    }
}

A The test fails at the second assertion and continues to the third.

B The test passes because the first two assertions are correct.

C The test fails at the first assertion and stops executing further assertions.

D The test fails at the third assertion with an AssertionError.

💡 Hint

JUnit stops executing a test method when an assertion fails.

The first two assertions pass, but the third assertion fails because 2 + 2 equals 4, not 6. The test fails at the third assertion.

🔧 Debug

advanced

Identify the problem with multiple assertions in one test

Given this JUnit test method:

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

public class CalculatorTest {
    @Test
    void testAddAndSubtract() {
        assertEquals(7, Calculator.add(3, 4));
        assertEquals(1, Calculator.subtract(5, 4));
        assertEquals(10, Calculator.add(5, 5));
    }
}

If the second assertion fails, what is the main issue with having all assertions in one test method?

A The test stops at the failing assertion, so the third assertion is never checked.

B JUnit will report all assertion failures in the test method at once.

C The test will pass if any one assertion passes.

D The test method will run slower because of multiple assertions.

💡 Hint

Think about how JUnit handles assertion failures inside a test method.

When an assertion fails, JUnit stops executing the current test method, so any assertions after the failure are not run. This can hide other potential failures.

❓ framework

advanced

Which JUnit feature helps test multiple assertions without stopping at first failure?

JUnit 5 introduced a feature that allows multiple assertions to be checked in a single test method, reporting all failures at once instead of stopping at the first failure. What is this feature called?

A assertGroup

B assertMultiple

C assertAll

D assertBatch

💡 Hint

It groups assertions and reports all failures together.

The assertAll method allows grouping multiple assertions so that all are executed and all failures are reported together.

❓ Predict Output

expert

What is the output of this JUnit test using assertAll?

Analyze the following JUnit 5 test method:

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

public class MathTest {
    @Test
    void testMultipleFailures() {
        assertAll("Multiple checks",
            () -> assertEquals(10, 5 + 5),
            () -> assertEquals(3, 1 + 1),
            () -> assertTrue(2 > 3)
        );
    }
}

What will be the result when this test runs?

A The test fails reporting only the second assertion failure.

B The test fails reporting two assertion failures: second and third assertions.

C The test fails reporting only the third assertion failure.

D The test passes because the first assertion is correct.

💡 Hint

assertAll runs all assertions and reports all failures together.

The first assertion passes (5 + 5 = 10). The second assertion fails (1 + 1 = 2, expected 3). The third assertion fails (2 > 3 is false). Both failures are reported together.

Practice

1. Why is it recommended to have only one assertion per test in JUnit testing?

easy

A. It makes tests simpler and easier to understand.

B. It reduces the total number of tests needed.

C. It allows multiple failures to be reported at once.

D. It speeds up the execution time of tests significantly.

Solution

1. Step 1: Understand test simplicity

   Having one assertion per test keeps the test focused and easy to read.

2. Step 2: Understand failure clarity

   When a test fails, it is clear exactly what went wrong because only one condition is checked.

3. Final Answer:

   It makes tests simpler and easier to understand. -> Option A

4. Quick Check:

   One assertion = simple test [OK]

Hint: One assertion means clear, simple tests [OK]

Common Mistakes:

• Thinking multiple assertions speed up tests
• Believing one test must cover many cases
• Confusing test simplicity with fewer tests

2. Which of the following JUnit test method structures follows the single assertion per test best practice?

easy

A. @Test
void testSum() {
assertTrue(sum(2, 3) > 0);
assertTrue(sum(3, 4) > 0);
}

B. @Test
void testSum() {
assertEquals(5, sum(2, 3));
assertEquals(7, sum(3, 4));
}

C. @Test
void testSum() {
int result = sum(2, 3);
assertTrue(result > 0);
assertEquals(5, result);
}

D. @Test
void testSum() {
assertEquals(5, sum(2, 3));
}

@Test
void testSumNegative() {
assertEquals(-1, sum(-2, 1));
}

Solution

1. Step 1: Review each test method

   @Test void testSum() { assertEquals(5, sum(2, 3)); } @Test void testSumNegative() { assertEquals(-1, sum(-2, 1)); } splits checks into two separate test methods, each with one assertion.

2. Step 2: Compare with other options

   Options B, C, and D have multiple assertions in one test method, which breaks the single assertion rule.

3. Final Answer:

   Separate tests with one assertion each. -> Option D

4. Quick Check:

   One assertion per test method = @Test void testSum() { assertEquals(5, sum(2, 3)); } @Test void testSumNegative() { assertEquals(-1, sum(-2, 1)); } [OK]

Hint: One test, one assertion, split tests if needed [OK]

Common Mistakes:

• Putting multiple assertions in one test method
• Not splitting tests logically
• Confusing assertTrue with assertEquals usage

3. Given the following JUnit test, what will be the test result if sum(2, 3) returns 6?

@Test
void testSum() {
  assertEquals(5, sum(2, 3));
}

medium

A. Test passes successfully.

B. Test fails with an assertion error.

C. Test throws a compilation error.

D. Test is ignored during execution.

Solution

1. Step 1: Understand assertEquals behavior

   assertEquals expects the first and second values to be equal for the test to pass.

2. Step 2: Compare expected and actual values

   Expected is 5, actual is 6, so they do not match, causing failure.

3. Final Answer:

   Test fails with an assertion error. -> Option B

4. Quick Check:

   Expected != actual -> fail [OK]

Hint: Mismatch in assertEquals causes failure [OK]

Common Mistakes:

• Assuming test passes if values differ
• Confusing compilation errors with assertion failures
• Thinking test is skipped without @Ignore

4. Identify the problem in this JUnit test method regarding the single assertion per test principle:

@Test
void testUser() {
  assertEquals("John", user.getName());
  assertEquals(30, user.getAge());
}

medium

A. The test method is missing the @Before annotation.

B. The assertEquals methods are used incorrectly with wrong parameter order.

C. The test method has multiple assertions, making it harder to find failures.

D. The test method should use assertTrue instead of assertEquals.

Solution

1. Step 1: Check number of assertions

   The test has two assertEquals calls, violating the single assertion rule.

2. Step 2: Understand impact of multiple assertions

   Multiple assertions make it unclear which check failed if the test fails.

3. Final Answer:

   The test method has multiple assertions, making it harder to find failures. -> Option C

4. Quick Check:

   Multiple assertions = unclear failure [OK]

Hint: One assertion per test avoids confusion [OK]

Common Mistakes:

• Thinking multiple assertions are always better
• Confusing @Before with test assertions
• Misusing assertEquals parameter order

5. You have a method calculateDiscount that returns a discount percentage based on user type and purchase amount. How should you write JUnit tests following the single assertion per test debate best practice?

hard

A. Write separate test methods for each user type and purchase amount combination, each with one assertion.

B. Write tests only for the most common user type and skip others.

C. Write one test method that asserts the discount is never negative, ignoring user types.

D. Write one test method with multiple assertions checking all user types and amounts.

Solution

1. Step 1: Understand test coverage needs

   Each user type and purchase amount combination can behave differently and needs separate testing.

2. Step 2: Apply single assertion per test

   Writing separate test methods with one assertion each keeps tests clear and failures easy to locate.

3. Final Answer:

   Write separate test methods for each user type and purchase amount combination, each with one assertion. -> Option A

4. Quick Check:

   Separate focused tests = Write separate test methods for each user type and purchase amount combination, each with one assertion. [OK]

Hint: Split tests by case, one assertion each [OK]

Common Mistakes:

• Combining many assertions in one test
• Ignoring edge cases for coverage
• Skipping tests for less common inputs