Test class organization in JUnit - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a JUnit test class.

JUnit

public class [1] {

}

Drag options to blanks, or click blank then click option'

Acalculator

Bcalculate

CTestCalculator

DCalculatorTest

Attempts:

3 left

💡 Hint

Common Mistakes

Using method names or lowercase names as class names.

Not indicating the class is a test class.

The test class name should clearly indicate it is a test, commonly by ending with 'Test'. 'CalculatorTest' is a good name for testing Calculator class.

2fill in blank

medium

Complete the code to import the JUnit 5 test annotation.

JUnit

import org.junit.jupiter.api.[1];

Drag options to blanks, or click blank then click option'

ATest

BBeforeEach

CTestCase

DTestRunner

Attempts:

3 left

💡 Hint

Common Mistakes

Importing 'TestCase' which is from older JUnit versions.

Confusing setup annotations with test annotations.

The '@Test' annotation marks a method as a test method in JUnit 5.

3fill in blank

hard

Fix the error in the test method declaration by completing the annotation.

JUnit

public class CalculatorTest {

    [1]
    public void addNumbers() {
        // test code
    }
}

Drag options to blanks, or click blank then click option'

A@TestMethod

B@Test

C@TestCase

D@TestRun

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect annotation names like '@TestMethod' or '@TestCase'.

Forgetting the '@' symbol.

The correct annotation to mark a test method in JUnit 5 is '@Test'.

4fill in blank

hard

Fill both blanks to declare a setup method that runs before each test.

JUnit

public class CalculatorTest {

    [1]
    void [2]() {
        // setup code
    }
}

Drag options to blanks, or click blank then click option'

A@BeforeEach

Bsetup

Cinitialize

D@BeforeAll

Attempts:

3 left

💡 Hint

Common Mistakes

Using '@BeforeAll' which runs once before all tests, not before each.

Using method names that do not describe setup.

'@BeforeEach' marks a method to run before each test method. 'setup' is a common method name for initialization.

5fill in blank

hard

Fill all three blanks to write a test method that asserts two values are equal.

JUnit

import static org.junit.jupiter.api.Assertions.[1];

public class CalculatorTest {

    @Test
    void testAddition() {
        int expected = 5;
        int actual = 2 + 3;
        [2]([3], actual);
    }
}

Drag options to blanks, or click blank then click option'

AassertEquals

BassertTrue

Cexpected

DassertFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'assertTrue' or 'assertFalse' instead of 'assertEquals' for equality check.

Swapping expected and actual arguments.

'assertEquals' is used to check if two values are equal. The first argument is the expected value, here 'expected'.

Practice

1. What is the main purpose of organizing test methods inside a test class in JUnit?

easy

A. To group related tests for better readability and maintenance

B. To make tests run faster by parallel execution

C. To reduce the number of test cases needed

D. To avoid writing assertions in test methods

Solution

1. Step 1: Understand test class role

   Test classes group related test methods logically to keep tests organized and easy to find.

2. Step 2: Identify benefits of grouping

   Grouping improves readability and helps maintain tests as the project grows.

3. Final Answer:

   To group related tests for better readability and maintenance -> Option A

4. Quick Check:

   Test class organization = Group related tests [OK]

Hint: Test classes group related tests logically [OK]

Common Mistakes:

• Thinking test classes speed up test execution
• Believing test classes reduce test count
• Confusing test class purpose with assertion writing

2. Which of the following is the correct way to name a JUnit test class for testing a Calculator class?

easy

A. CalcTestClass

B. TestCalculatorClass

C. CalculatorTest

D. CalculatorTesting

Solution

1. Step 1: Review common naming conventions

   JUnit test classes usually use the pattern ClassNameTest for clarity and consistency.

2. Step 2: Match options to convention

   "CalculatorTest" follows this convention exactly, making it clear and standard.

3. Final Answer:

   CalculatorTest -> Option C

4. Quick Check:

   Test class naming = ClassNameTest [OK]

Hint: Use ClassNameTest format for test classes [OK]

Common Mistakes:

• Using vague or inconsistent test class names
• Adding unnecessary words like 'Class' or 'Testing'
• Not matching test class name to the class under test

3. Given the following JUnit test class snippet, what will be the output when running the tests?

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

public class MathUtilsTest {
    @Test
    void testAdd() {
        assertEquals(5, 2 + 3);
    }

    @Test
    void testSubtract() {
        assertEquals(1, 3 - 2);
    }

    @Test
    void testMultiply() {
        assertEquals(6, 2 * 3);
    }
}

medium

A. testAdd fails, others pass

B. All tests pass

C. testSubtract fails, others pass

D. testMultiply fails, others pass

Solution

1. Step 1: Check each assertion correctness

   testAdd: 2 + 3 = 5 matches expected 5; testSubtract: 3 - 2 = 1 matches expected 1; testMultiply: 2 * 3 = 6 matches expected 6.

2. Step 2: Confirm all tests pass

   Since all assertions match expected values, all tests will pass successfully.

3. Final Answer:

   All tests pass -> Option B

4. Quick Check:

   Assertions correct = All pass [OK]

Hint: Verify each assertion matches expected result [OK]

Common Mistakes:

• Assuming tests fail without checking assertion values
• Confusing test method names with test results
• Ignoring that all assertions are correct

4. Identify the problem in the following JUnit test class organization:

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

class StringUtils {
    static boolean isEmpty(String str) {
        return str.length() == 0;
    }
}

public class StringUtilsTest {
    @Test
    void testIsEmpty() {
        assertTrue(StringUtils.isEmpty(""));
    }

    void testIsNotEmpty() {
        assertFalse(StringUtils.isEmpty("abc"));
    }
}

medium

A. Test methods should be static

B. Incorrect assertion method used in testIsEmpty

C. Test class name does not match tested class

D. Missing @Test annotation on testIsNotEmpty method

Solution

1. Step 1: Check annotations on test methods

   testIsEmpty has @Test annotation, but testIsNotEmpty does not, so it won't run as a test.

2. Step 2: Understand impact of missing annotation

   Without @Test, testIsNotEmpty is ignored during test execution, missing coverage.

3. Final Answer:

   Missing @Test annotation on testIsNotEmpty method -> Option D

4. Quick Check:

   All test methods need @Test [OK]

Hint: Every test method must have @Test annotation [OK]

Common Mistakes:

• Forgetting @Test annotation on test methods
• Thinking test methods must be static
• Confusing assertion methods with annotations

5. You have a test class with multiple test methods for a UserService. You want to organize tests by feature (e.g., login, registration) within the same class. Which is the best practice to keep the test class organized and maintainable?

hard

A. Group test methods by feature using nested classes or clear method name prefixes

B. Put all tests in one method to reduce class size

C. Create separate test classes for each feature without grouping

D. Use random order of test methods to avoid bias

Solution

1. Step 1: Consider organization within a test class

   Grouping related tests by feature improves readability and helps maintain tests logically.

2. Step 2: Use nested classes or naming conventions

   Nested classes or method name prefixes (e.g., loginTest_*, registrationTest_*) clearly separate features inside one test class.

3. Final Answer:

   Group test methods by feature using nested classes or clear method name prefixes -> Option A

4. Quick Check:

   Organize tests by feature inside class [OK]

Hint: Use nested classes or prefixes to group feature tests [OK]

Common Mistakes:

• Putting all tests in one method reduces clarity
• Creating too many small classes without grouping
• Ignoring logical grouping harms maintainability