Single assertion per test debate in JUnit - Framework Patterns

Framework Mode - Single assertion per test debate

Folder Structure

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

Test Framework Layers

• Driver Layer: Manages WebDriver setup and teardown for browser control.
• Page Objects: Encapsulate UI elements and actions (e.g., LoginPage.java).
• Tests: Contains JUnit test classes with test methods and assertions.
• Utilities: Helper methods for common tasks like waits, data generation.
• Configuration: Holds environment settings, credentials, browser options.

Configuration Patterns

• Use TestConfig.java to load environment variables (e.g., dev, staging, prod).
• Use system properties or config files to select browser type (Chrome, Firefox).
• Store sensitive data like credentials securely, e.g., environment variables or encrypted files.
• Allow easy switching of test environments without code changes.

Test Reporting and CI/CD Integration

• Use JUnit's built-in reports for pass/fail results.
• Integrate with CI tools like Jenkins or GitHub Actions to run tests on code changes.
• Generate HTML or XML reports for detailed test results.
• Fail fast on assertion failure to save time.

Framework Design Principles

1. Clear Test Purpose: Each test should verify one behavior or scenario clearly.
2. Single Assertion Debate: Prefer one assertion per test for clarity, but multiple related assertions are acceptable if they test one logical outcome.
3. Readable Tests: Use descriptive test method names and comments to explain intent.
4. Reusable Page Objects: Keep UI interaction code separate from tests.
5. Fail Fast: Stop test execution on first failure to avoid misleading results.

Self Check

Where would you add a new test method that verifies the login error message appears when invalid credentials are used?

Key Result

Organize tests with clear layers and prefer one assertion per test for clarity, balancing practicality in JUnit frameworks.

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