This test verifies that converting "hello" to uppercase always returns "HELLO".
JUnit
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class StringTest {
@Test
void testToUpper() {
String result = "hello".toUpperCase();
assertEquals("HELLO", result);
}
}
Sample Program
This test checks that multiplying 4 by 2 always returns 8. The test is deterministic because the method multiplyByTwo always returns the same output for the same input.
JUnit
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class DeterministicTestExample {
int multiplyByTwo(int number) {
return number * 2;
}
@Test
void testMultiplyByTwo() {
intinput = 4;
int expected = 8;
int actual = multiplyByTwo(input);
assertEquals(expected, actual);
}
}
OutputSuccess
Important Notes
Deterministic tests do not rely on random numbers or current time.
Keep tests simple and predictable to avoid flaky results.
Use clear assertions to compare expected and actual results.
Summary
Deterministic tests always produce the same result for the same input.
They help make tests reliable and easy to trust.
Use assertions to check expected outcomes clearly.
Practice
(1/5)
1. What does it mean for a JUnit test to be deterministic?
easy
A. It always produces the same result given the same input
B. It runs faster than other tests
C. It uses random data each time it runs
D. It depends on external services to pass
Solution
Step 1: Understand the meaning of deterministic
Deterministic means something behaves the same way every time under the same conditions.
Step 2: Apply this to JUnit tests
A deterministic test always gives the same result when run with the same input and environment.
Final Answer:
It always produces the same result given the same input -> Option A
Quick Check:
Deterministic = Same result every time [OK]
Hint: Deterministic means repeatable results every run [OK]
Common Mistakes:
Confusing deterministic with fast execution
Thinking random data makes tests deterministic
Assuming external services guarantee determinism
2. Which of the following is the correct way to write a deterministic assertion in JUnit 5?
easy
A. assertNull(getRandomObject());
B. assertTrue(random.nextBoolean());
C. assertFalse(externalServiceCall());
D. assertEquals(expected, actual);
Solution
Step 1: Identify deterministic assertions
Deterministic assertions compare known expected values to actual results.
Step 2: Check each option
assertEquals(expected, actual); compares expected and actual values directly, which is deterministic. Options A, B, and D depend on random or external calls, which are not deterministic.
Final Answer:
assertEquals(expected, actual); -> Option D
Quick Check:
Deterministic assertions compare fixed expected and actual values [OK]
Hint: Use fixed expected values in assertions for determinism [OK]
Common Mistakes:
Using random values inside assertions
Calling external services in assertions
Assuming assertNull is always deterministic
3. Consider this JUnit test snippet:
int result = calculator.add(2, 3);
assertEquals(5, result);
What will be the test result if the add method always returns the sum of its inputs?
medium
A. Test will fail because 2 + 3 is not 5
B. Test will pass because the result matches expected
C. Test will fail due to syntax error
D. Test will be flaky and sometimes pass
Solution
Step 1: Understand the add method behavior
The add method returns the sum of inputs, so add(2, 3) returns 5.
Step 2: Check the assertion
The assertion expects 5 and the actual result is 5, so the assertion passes.
Final Answer:
Test will pass because the result matches expected -> Option B
Quick Check:
Expected 5, got 5 = pass [OK]
Hint: If expected equals actual, test passes [OK]
Common Mistakes:
Thinking 2 + 3 is not 5
Assuming syntax error without checking code
Believing test is flaky without randomness
4. This JUnit test sometimes fails:
@Test
void testRandomNumber() {
int num = new Random().nextInt(10);
assertTrue(num == 0);
}
What is the main reason this test is not deterministic?
medium
A. The test depends on random values causing different results
B. The test uses a new Random object each time
C. The assertion condition is incorrect
D. The test method is missing @BeforeEach annotation
Solution
Step 1: Identify randomness in the test
The test generates a random number each run, so output varies.
Step 2: Understand impact on determinism
Because the number changes, the test result can vary, making it non-deterministic.
Final Answer:
The test depends on random values causing different results -> Option A
Quick Check:
Random values cause non-determinism [OK]
Hint: Random values cause flaky tests, avoid them [OK]
Common Mistakes:
Thinking assertion condition is wrong
Believing new Random() fixes determinism
Confusing test annotations with determinism
5. You want to make this test deterministic:
@Test
void testCurrentTime() {
long time = System.currentTimeMillis();
assertTrue(time > 0);
}
Which approach best ensures determinism?
hard
A. Remove the assertion to avoid failures
B. Add Thread.sleep(1000) before assertion
C. Replace System.currentTimeMillis() with a fixed mock time value
D. Run the test multiple times and average results
Solution
Step 1: Identify non-deterministic part
System.currentTimeMillis() returns changing time, causing test to vary.
Step 2: Apply mocking for fixed value
Replacing it with a fixed mock value makes the test produce the same result every run.
Final Answer:
Replace System.currentTimeMillis() with a fixed mock time value -> Option C
Quick Check:
Fixed mock values ensure determinism [OK]
Hint: Mock changing values to fixed ones for deterministic tests [OK]
Common Mistakes:
Using sleep does not fix changing values
Removing assertions hides problems, not fix determinism
Averaging results does not guarantee same output
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.