Why fast tests enable frequent runs in JUnit - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to mark the test method with JUnit 5 annotation.

JUnit

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

public class CalculatorTest {
    [1]
    void testAddition() {
        int sum = 2 + 3;
        assertEquals(5, sum);
    }
}

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

A@AfterAll

B@BeforeEach

C@Test

D@Disabled

Attempts:

3 left

💡 Hint

Common Mistakes

Using @BeforeEach instead of @Test

Forgetting to add any annotation

Using @Disabled which skips the test

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

2fill in blank

medium

Complete the code to assert that the result equals 10.

JUnit

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

@Test
void testMultiplication() {
    int result = 2 * 5;
    [1](10, result);
}

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

AassertEquals

BassertTrue

CassertNull

DassertFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using assertTrue with equality expression instead of assertEquals

Using assertNull which checks for null values

assertEquals(expected, actual) checks if the actual value matches the expected value.

3fill in blank

hard

Fix the error in the test method to make it run correctly.

JUnit

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

@Test
void testDivision() {
    int result = 10 / 2;
    assertEquals(5, [1]);
}

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

Aresult

B10

C2

D5

Attempts:

3 left

💡 Hint

Common Mistakes

Using a literal number instead of the variable 'result'

Swapping expected and actual arguments

The actual value to check is the variable 'result', not a literal.

4fill in blank

hard

Fill both blanks to create a fast test that runs multiple times.

JUnit

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

@RepeatedTest([1])
void testFastAddition() {
    int sum = 1 + 1;
    assertEquals([2], sum);
}

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

A5

B2

C3

D10

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong number of repetitions

Asserting wrong expected sum

RepeatedTest(10) runs the test 10 times; sum of 1 + 1 equals 2.

5fill in blank

hard

Fill all three blanks to create a test that fails fast on wrong input.

JUnit

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

@Test
void testFailFast() {
    int input = [1];
    int expected = [2];
    int actual = input * 2;
    assertEquals([3], actual);
}

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

A3

B4

C6

D5

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching expected and actual values

Using input that does not match expected output

Input 3 doubled is 6, so expected and actual should be 6 to pass the test.

Practice

1.

Why is it important to have fast tests when using JUnit?

easy

A. Because fast tests use more memory

B. Because slow tests are more accurate

C. Because fast tests allow running them frequently to catch bugs early

D. Because fast tests require more setup time

Solution

1. Step 1: Understand the role of test speed

   Fast tests run quickly, so developers can run them many times during development.

2. Step 2: Connect frequent runs to bug detection

   Running tests often helps find bugs early, making fixing easier and faster.

3. Final Answer:

   Because fast tests allow running them frequently to catch bugs early -> Option C

4. Quick Check:

   Fast tests = frequent runs = early bug detection [OK]

Hint: Fast tests mean more runs and quicker bug fixes [OK]

Common Mistakes:

• Thinking slow tests are better for accuracy
• Confusing test speed with memory usage
• Believing fast tests need more setup

2.

Which JUnit annotation is used to mark a method as a test that should run quickly?

easy

A. @SlowTest

B. @Test

C. @FastTest

D. @RunQuick

Solution

1. Step 1: Recall JUnit test method annotation

   JUnit uses @Test to mark methods as tests.

2. Step 2: Understand that speed-specific annotations are not standard

   Annotations like @FastTest or @SlowTest are not part of standard JUnit.

3. Final Answer:

   @Test -> Option B

4. Quick Check:

   JUnit test method = @Test [OK]

Hint: Standard JUnit test methods use @Test annotation [OK]

Common Mistakes:

• Assuming @FastTest or @SlowTest are standard JUnit annotations
• Confusing custom annotations with JUnit basics
• Using non-existent annotations like @RunQuick

3.

Consider this JUnit test method:

  @Test
  void testSum() {
    int result = 0;
    for (int i = 1; i <= 3; i++) {
      result += i;
    }
    assertEquals(6, result);
  }

What will be the test result when run?

medium

A. Test passes because sum 1+2+3 equals 6

B. Test fails because result is 5

C. Test fails due to syntax error

D. Test throws runtime exception

Solution

1. Step 1: Calculate the sum in the loop

   The loop adds 1 + 2 + 3, resulting in 6.

2. Step 2: Check the assertion

   The assertion expects 6, which matches the calculated result.

3. Final Answer:

   Test passes because sum 1+2+3 equals 6 -> Option A

4. Quick Check:

   Sum 1+2+3 = 6 matches assertEquals(6, result) [OK]

Hint: Sum 1 to 3 is 6, matches assertion [OK]

Common Mistakes:

• Miscounting the sum as 5
• Thinking there is a syntax error
• Assuming runtime exception without cause

4.

Look at this JUnit test snippet:

  @Test
  void testDivide() {
    int result = 10 / 0;
    assertEquals(0, result);
  }

What is the problem and how to fix it for fast, frequent runs?

medium

A. No problem; test runs fine

B. Assertion is wrong; change expected value to 10

C. Test method missing @Test annotation

D. Division by zero causes runtime error; fix by avoiding zero divisor

Solution

1. Step 1: Identify the error in test code

   Dividing by zero causes an ArithmeticException at runtime.

2. Step 2: Fix the error to keep tests fast and stable

   Avoid dividing by zero by checking divisor or changing value to non-zero.

3. Final Answer:

   Division by zero causes runtime error; fix by avoiding zero divisor -> Option D

4. Quick Check:

   Zero divisor = runtime error; fix divisor [OK]

Hint: Never divide by zero in tests to avoid crashes [OK]

Common Mistakes:

• Ignoring runtime exceptions
• Changing assertion without fixing error
• Missing @Test annotation confusion

5.

You have a large test suite that takes 30 minutes to run. How can you apply the principle of fast tests to enable frequent runs in JUnit?

hard

A. Split tests into small, independent units that run quickly

B. Add more assertions to each test to cover more cases

C. Run all tests only once a day to save time

D. Combine multiple tests into one big test method

Solution

1. Step 1: Understand the problem with long test suites

   Long tests slow down feedback and reduce how often tests run.

2. Step 2: Apply fast test principle

   Splitting tests into small, fast units allows running tests frequently and catching bugs early.

3. Final Answer:

   Split tests into small, independent units that run quickly -> Option A

4. Quick Check:

   Small fast tests = frequent runs = quick feedback [OK]

Hint: Small tests run fast and encourage frequent checks [OK]

Common Mistakes:

• Adding more assertions slows tests
• Running tests less often delays bug detection
• Combining tests makes them slower