Test result publishing in JUnit - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

JUnit test result for a passing test

What is the test execution result shown in the JUnit XML report for this passing test?

JUnit

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

public class SampleTest {
    @Test
    void testAlwaysPasses() {
        assertTrue(5 > 1);
    }
}

A <testcase classname="SampleTest" name="testAlwaysPasses" time="0.001"><error message="Exception thrown"/></testcase>

B <testcase classname="SampleTest" name="testAlwaysPasses" time="0.001"/>

C <testcase classname="SampleTest" name="testAlwaysPasses" time="0.001"><skipped/></testcase>

D <testcase classname="SampleTest" name="testAlwaysPasses" time="0.001"><failure message="Assertion failed"/></testcase>

💡 Hint

Passing tests do not have failure, error, or skipped tags in the JUnit XML report.

In JUnit XML reports, a passing test is represented by a element without child elements like , , or . Option B correctly shows this.

❓ Predict Output

intermediate

JUnit test result for a failed assertion

What is the test execution result shown in the JUnit XML report for this failing test?

JUnit

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

public class SampleTest {
    @Test
    void testFails() {
        assertEquals(5, 3);
    }
}

A <testcase classname="SampleTest" name="testFails" time="0.001"><failure message="expected:&lt;5&gt; but was:&lt;3&gt;"/></testcase>

B <testcase classname="SampleTest" name="testFails" time="0.001"/>

C <testcase classname="SampleTest" name="testFails" time="0.001"><error message="NullPointerException"/></testcase>

D <testcase classname="SampleTest" name="testFails" time="0.001"><skipped/></testcase>

💡 Hint

Failed assertions are reported with a tag including the failure message.

JUnit reports failed assertions inside the tag with a message describing the assertion error. Option A correctly shows this.

❓ assertion

advanced

Correct assertion to verify test failure message in JUnit

Which assertion correctly verifies that a JUnit test failure message contains the text "expected:<5> but was:<3>"?

A assertTrue(failureMessage.contains("expected:<5> but was:<3>"));

B assertEquals("expected:<5> but was:<3>", failureMessage);

C assertNull(failureMessage);

D assertFalse(failureMessage.contains("expected:<5> but was:<3>"));

💡 Hint

Use assertTrue to check if the failure message contains the expected substring.

The failure message may contain additional text, so checking if it contains the substring is correct. Option A uses assertTrue with contains(), which is appropriate.

🔧 Debug

advanced

Identify the cause of missing test results in JUnit report

A JUnit XML report is missing test results for some tests. Which of the following is the most likely cause?

A Test methods throw checked exceptions.

B Tests use assertTrue assertions instead of assertEquals.

C Test methods have void return type.

D Tests are annotated with @Test but the test class is not public.

💡 Hint

JUnit requires test classes to be public to discover and run tests.

JUnit only runs tests in public classes. If the test class is not public, tests are not executed and results are missing. Other options do not prevent test execution or reporting.

❓ framework

expert

Best practice for publishing JUnit test results in CI pipeline

In a CI pipeline, which approach ensures reliable publishing of JUnit test results for all test runs, including flaky tests and retries?

A Manually edit the JUnit XML files to remove duplicate test cases before publishing.

B Only publish the JUnit XML file from the first test run, ignoring retries.

C Configure the CI to collect and merge all JUnit XML files generated by each test run and retry.

D Publish test results only if the test run passes without retries.

💡 Hint

CI tools often support merging multiple JUnit XML files to aggregate results.

Merging all JUnit XML files from all runs and retries ensures complete and accurate test reporting. Ignoring retries or manual editing risks losing data or errors.