Bird
Raised Fist0
JUnittesting~8 mins

Mockito dependency setup in JUnit - Framework Patterns

Choose your learning style10 modes available
Framework Mode - Mockito dependency setup
Folder Structure for JUnit + Mockito Project
project-root/
├── src/
│   ├── main/
│   │   └── java/
│   │       └── com/example/app/
│   │           └── (application source code)
│   └── test/
│       └── java/
│           └── com/example/app/
│               └── (test classes using JUnit and Mockito)
├── pom.xml (Maven build file with dependencies)
└── build.gradle (Gradle build file with dependencies)
    
Test Framework Layers
  • Test Classes: JUnit test classes where Mockito mocks are used to isolate units.
  • Mock Objects: Created with Mockito to simulate dependencies.
  • Test Utilities: Helper methods or classes to initialize mocks or common test data.
  • Configuration: Build files (pom.xml or build.gradle) to manage Mockito and JUnit dependencies.
Configuration Patterns for Mockito Dependency Setup

Use build tools to add Mockito and JUnit dependencies:

Maven (pom.xml)

<dependencies>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.9.3</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-engine</artifactId>
    <version>5.9.3</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>5.4.0</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Gradle (build.gradle)

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.9.3'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.9.3'
    testImplementation 'org.mockito:mockito-core:5.4.0'
}

These dependencies ensure Mockito and JUnit are available only during testing.

Test Reporting and CI/CD Integration

JUnit and Mockito tests integrate with build tools to produce reports:

  • JUnit Reports: XML and HTML reports generated by Maven Surefire or Gradle test tasks.
  • CI/CD: Jenkins, GitHub Actions, or GitLab CI run tests automatically on code changes.
  • Mockito: Works inside JUnit tests; failures show mock verification errors in reports.
Best Practices for Mockito Dependency Setup
  • Use the latest stable versions of Mockito and JUnit for compatibility and features.
  • Scope dependencies as test to avoid bloating production builds.
  • Keep test dependencies separate from main code dependencies.
  • Use build tool plugins (Maven Surefire, Gradle Test) to run tests and generate reports.
  • Document dependency versions in build files for easy updates and team sharing.
Self Check

Where in this folder structure would you add a new test class that uses Mockito to mock a service?

Key Result
Add Mockito and JUnit dependencies in build files to enable mocking in test classes under src/test/java.

Practice

(1/5)
1. What is the main purpose of setting up Mockito as a dependency in a JUnit project?
easy
A. To automatically generate user interfaces
B. To create fake objects for testing without using real implementations
C. To improve the performance of the application in production
D. To deploy the application to a server

Solution

  1. Step 1: Understand Mockito's role

    Mockito is a tool used to create mock objects that simulate real objects in tests.
  2. Step 2: Identify the purpose in testing

    Using mocks helps isolate the code under test by replacing dependencies with fake versions.
  3. Final Answer:

    To create fake objects for testing without using real implementations -> Option B
  4. Quick Check:

    Mockito = mock objects for testing [OK]
Hint: Mockito creates fake objects to test code easily [OK]
Common Mistakes:
  • Thinking Mockito improves production performance
  • Confusing Mockito with UI tools
  • Assuming Mockito deploys applications
2. Which of the following is the correct Maven dependency snippet to add Mockito version 4.11.0 for test scope?
easy
A. org.mockito mockito-core 4.11.0 test
B. org.mockito mockito-core 4.11.0
C. org.mockito mockito-all 3.0.0 compile
D. org.mockito mockito-core 5.0.0 test

Solution

  1. Step 1: Check groupId and artifactId

    The correct groupId is 'org.mockito' and artifactId is 'mockito-core' for Mockito library.
  2. Step 2: Verify version and scope

    Version 4.11.0 is correct and scope should be 'test' to use Mockito only during testing.
  3. Final Answer:

    Correct Maven dependency with version 4.11.0 and test scope -> Option A
  4. Quick Check:

    Maven dependency with test scope = org.mockito mockito-core 4.11.0 test [OK]
Hint: Use 'mockito-core' with test scope and correct version [OK]
Common Mistakes:
  • Omitting the test scope
  • Using wrong artifactId like 'mockito-all'
  • Using incorrect or too new version
3. You want to use Mockito in a JUnit 5 project with Gradle. Which of the following Gradle dependency setups correctly adds Mockito version 4.11.0 only for test implementation?
easy
A. testImplementation 'org.mockito:mockito-core:4.11.0'
B. implementation 'org.mockito:mockito-core:4.11.0'
C. compileOnly 'org.mockito:mockito-core:4.11.0'
D. runtimeOnly 'org.mockito:mockito-core:4.11.0'

Solution

  1. Step 1: Understand Gradle scopes

    testImplementation means the dependency is available only during test compilation and runtime.
  2. Step 2: Choose correct scope for Mockito

    Mockito is used only in tests, so testImplementation is the correct scope.
  3. Final Answer:

    testImplementation 'org.mockito:mockito-core:4.11.0' -> Option A
  4. Quick Check:

    Mockito test dependency = testImplementation [OK]
Hint: Use testImplementation for test-only dependencies in Gradle [OK]
Common Mistakes:
  • Using implementation instead of testImplementation
  • Using compileOnly which excludes runtime
  • Using runtimeOnly which excludes compile time
4. Given the following JUnit test code snippet using Mockito, what will be the output of System.out.println(mockService.getData());?
import static org.mockito.Mockito.*;

public class ServiceTest {
  @Test
  void testGetData() {
    DataService mockService = mock(DataService.class);
    when(mockService.getData()).thenReturn("Mocked Data");
    System.out.println(mockService.getData());
  }
}
medium
A. Original data from DataService
B. null
C. Throws NullPointerException
D. Mocked Data

Solution

  1. Step 1: Understand mock behavior

    The mock object returns what is specified in when().thenReturn(), here "Mocked Data".
  2. Step 2: Check the printed output

    Calling getData() on mockService returns "Mocked Data", so it prints that string.
  3. Final Answer:

    Mocked Data -> Option D
  4. Quick Check:

    Mockito when().thenReturn() sets output = Mocked Data [OK]
Hint: when().thenReturn() sets mock method output [OK]
Common Mistakes:
  • Expecting null because it's a mock
  • Assuming real method runs
  • Thinking it throws an exception
5. Identify the error in the following Mockito setup code snippet:
import static org.mockito.Mockito.*;

public class UserServiceTest {
  @Mock
  UserRepository repo;

  @Test
  void testUser() {
    when(repo.findUser()).thenReturn(new User("Alice"));
    UserService service = new UserService(repo);
    assertEquals("Alice", service.getUserName());
  }
}
medium
A. Incorrect method name findUser() should be getUser()
B. UserService constructor should not accept repo
C. Missing MockitoAnnotations.openMocks(this) to initialize @Mock fields
D. assertEquals parameters are reversed

Solution

  1. Step 1: Check @Mock initialization

    @Mock fields need initialization, usually by calling MockitoAnnotations.openMocks(this) in setup.
  2. Step 2: Verify test setup completeness

    Without initialization, repo remains null causing NullPointerException when used.
  3. Final Answer:

    Missing MockitoAnnotations.openMocks(this) to initialize @Mock fields -> Option C
  4. Quick Check:

    @Mock requires initialization = Missing MockitoAnnotations.openMocks(this) to initialize @Mock fields [OK]
Hint: Always initialize @Mock with MockitoAnnotations.openMocks(this) [OK]
Common Mistakes:
  • Forgetting to initialize @Mock fields
  • Assuming @Mock works without setup
  • Mixing method names without checking
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