Bird
Raised Fist0
JUnittesting~10 mins

Fake objects in JUnit - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to create a fake object for testing.

JUnit
FakeDatabase fakeDb = mock(FakeDatabase.class);
fakeDb.[1]("testUser");
Drag options to blanks, or click blank then click option'
AaddUser
BupdateUser
Cconnect
DdeleteUser
Attempts:
3 left
💡 Hint
Common Mistakes
Using connect instead of addUser will not add a user.
Using deleteUser or updateUser will not add a new user.
2fill in blank
medium

Complete the code to verify the fake object's method was called.

JUnit
verify(fakeDb).[1]("testUser");
Drag options to blanks, or click blank then click option'
AupdateUser
Bconnect
CaddUser
DdeleteUser
Attempts:
3 left
💡 Hint
Common Mistakes
Verifying connect does not check user addition.
Verifying deleteUser or updateUser is unrelated to adding a user.
3fill in blank
hard

Fix the error in the fake object setup to return a value.

JUnit
when(fakeDb.[1]("testUser")).thenReturn(true);
Drag options to blanks, or click blank then click option'
Aconnect
BuserExists
CaddUser
DdeleteUser
Attempts:
3 left
💡 Hint
Common Mistakes
Trying to stub addUser which might be void causes errors.
connect and deleteUser do not return boolean values.
4fill in blank
hard

Fill both blanks to create a fake object and stub a method.

JUnit
FakeDatabase fakeDb = mock([1].class);
when(fakeDb.[2]("admin")).thenReturn(true);
Drag options to blanks, or click blank then click option'
AFakeDatabase
BRealDatabase
CuserExists
DaddUser
Attempts:
3 left
💡 Hint
Common Mistakes
Using RealDatabase instead of FakeDatabase defeats the purpose of a fake.
Stubbing addUser instead of userExists will not return a boolean.
5fill in blank
hard

Fill all three blanks to verify method calls and stub behavior on a fake object.

JUnit
FakeDatabase fakeDb = mock([1].class);
when(fakeDb.[2]("guest")).thenReturn(false);
verify(fakeDb).[3]("guest");
Drag options to blanks, or click blank then click option'
AFakeDatabase
BRealDatabase
CuserExists
DaddUser
Attempts:
3 left
💡 Hint
Common Mistakes
Using RealDatabase instead of FakeDatabase.
Verifying addUser instead of userExists causes test failures.
Stubbing addUser which does not return a value.

Practice

(1/5)
1. What is the main purpose of using a fake object in JUnit testing?
easy
A. To replace a real component with a simple version for controlled testing
B. To speed up the compilation of test classes
C. To generate random test data automatically
D. To log test execution details to a file

Solution

  1. Step 1: Understand the role of fake objects

    Fake objects are simplified versions of real components used in tests to isolate the code under test.
  2. Step 2: Identify the main purpose

    The main purpose is to replace real parts that might be slow, unavailable, or unpredictable with controlled versions.
  3. Final Answer:

    To replace a real component with a simple version for controlled testing -> Option A
  4. Quick Check:

    Fake objects replace real parts for testing [OK]
Hint: Fake objects replace real parts with simple versions [OK]
Common Mistakes:
  • Confusing fake objects with mocks or stubs
  • Thinking fake objects generate random data
  • Assuming fake objects speed up compilation
2. Which of the following is the correct way to define a fake object class in Java implementing an interface DataService?
easy
A. public class FakeDataService { int getData() { return 42; } }
B. public class FakeDataService extends DataService { public int getData() { return 42; } }
C. public class FakeDataService implements DataService { public int getData() { return 42; } }
D. public interface FakeDataService implements DataService { int getData(); }

Solution

  1. Step 1: Recall Java syntax for implementing interfaces

    In Java, a class implements an interface using the implements keyword and must provide method implementations.
  2. Step 2: Check each option

    public class FakeDataService implements DataService { public int getData() { return 42; } } correctly uses implements and defines the method. public class FakeDataService extends DataService { public int getData() { return 42; } } incorrectly uses extends with an interface. public interface FakeDataService implements DataService { int getData(); } wrongly declares an interface implementing another interface with method body. public class FakeDataService { int getData() { return 42; } } lacks interface implementation.
  3. Final Answer:

    public class FakeDataService implements DataService { public int getData() { return 42; } } -> Option C
  4. Quick Check:

    Class implements interface with 'implements' keyword [OK]
Hint: Use 'implements' keyword to define fake class for interface [OK]
Common Mistakes:
  • Using 'extends' instead of 'implements' for interfaces
  • Defining interface instead of class for fake
  • Omitting method implementation in fake class
3. Given the following fake object and test code, what will be the output of the assertion?
interface Calculator { int add(int a, int b); }
class FakeCalculator implements Calculator {
  public int add(int a, int b) { return 10; }
}

@Test
void testAdd() {
  Calculator calc = new FakeCalculator();
  assertEquals(10, calc.add(3, 7));
}
medium
A. Runtime exception due to wrong method signature
B. Test fails because 3 + 7 is 10
C. Compilation error due to missing override annotation
D. Test passes because fake returns fixed 10

Solution

  1. Step 1: Analyze the fake object's method

    The add method in FakeCalculator always returns 10 regardless of inputs.
  2. Step 2: Check the assertion in the test

    The test asserts that calc.add(3, 7) equals 10, which matches the fake's return value.
  3. Final Answer:

    Test passes because fake returns fixed 10 -> Option D
  4. Quick Check:

    Fake returns fixed value matching assertion [OK]
Hint: Fake returns fixed value; assertion matches it [OK]
Common Mistakes:
  • Expecting real addition instead of fake's fixed return
  • Confusing compilation errors with missing annotations
  • Assuming runtime exceptions without cause
4. Identify the error in this fake object implementation:
interface UserRepository {
  String findUserName(int id);
}

class FakeUserRepository implements UserRepository {
  public String findUserName() {
    return "TestUser";
  }
}
medium
A. Method signature does not match interface method
B. Class should be abstract to implement interface
C. Return type String is incorrect
D. Interface cannot be implemented by a class

Solution

  1. Step 1: Compare method signatures

    The interface method findUserName requires an int id parameter, but the fake method has no parameters.
  2. Step 2: Understand Java interface implementation rules

    Implementing classes must match method signatures exactly, including parameters.
  3. Final Answer:

    Method signature does not match interface method -> Option A
  4. Quick Check:

    Method signatures must match interface exactly [OK]
Hint: Check method parameters match interface exactly [OK]
Common Mistakes:
  • Ignoring method parameters in fake implementation
  • Thinking return type mismatch is the error
  • Believing class must be abstract to implement interface
5. You want to test a service that depends on a slow external API. Which approach best uses a fake object to improve test speed and reliability?
hard
A. Use the real API client but add delays in the test to wait for responses
B. Create a fake API client implementing the same interface that returns fixed test data instantly
C. Mock the API client to throw exceptions randomly during tests
D. Remove the API client dependency from the service code

Solution

  1. Step 1: Identify the problem with the real API

    The real API is slow and unreliable for tests, causing delays and flakiness.
  2. Step 2: Choose a fake object approach

    Creating a fake client that implements the same interface and returns fixed data instantly isolates the service and speeds tests.
  3. Step 3: Evaluate other options

    Use the real API client but add delays in the test to wait for responses slows tests further. Mock the API client to throw exceptions randomly during tests adds randomness, reducing reliability. Remove the API client dependency from the service code breaks service functionality.
  4. Final Answer:

    Create a fake API client implementing the same interface that returns fixed test data instantly -> Option B
  5. Quick Check:

    Fake replaces slow API with fast fixed data [OK]
Hint: Fake slow dependencies with fast fixed-return objects [OK]
Common Mistakes:
  • Adding delays instead of faking slow parts
  • Using mocks to add randomness in tests
  • Removing dependencies instead of faking them
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard