Intermediate JUnit & Mockito test (Intermediate)

Sample questions

5 sample questions from the Intermediate JUnit & Mockito test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which of the following statements correctly describes the difference between the `thenAnswer()` and `thenReturn()` methods in Mockito?

   1. The `thenAnswer()` method is used for static stubbing with a fixed return value, while `thenReturn()` is used for dynamic stubbing.
   2. Both `thenAnswer()` and `thenReturn()` are used for dynamic stubbing based on the method call or other variables.
   3. Both `thenAnswer()` and `thenReturn()` are used for static stubbing with fixed return values.
   4. The `thenAnswer()` method is used for dynamic stubbing, where the response depends on the method call or other variables, while `thenReturn()` is used for static stubbing with a fixed return value.

   Answer: D. The `thenAnswer()` method is used for dynamic stubbing, where the response depends on the method call or other variables, while `thenReturn()` is used for static stubbing with a fixed return value.

   `thenAnswer()` is used when you need to dynamically determine the return value of a stubbed method based on the method arguments or other conditions, whereas `thenReturn()` is used for stubbing with a fixed return value. `thenAnswer()` is suitable for complex scenarios that require dynamic behavior, while `thenReturn()` is best for simple, static stubbing.

2. Which statement accurately describes the functionality of JUnit 5 @TestFactory methods?

   1. JUnit 5 @TestFactory methods are used to create parameterized tests with @ValueSource or @CsvSource annotations.
   2. JUnit 5 @TestFactory methods are used to replace @ParameterizedTest for generating tests from external data sources.
   3. JUnit 5 @TestFactory methods are used to create static test cases that are defined at compile-time.
   4. JUnit 5 @TestFactory methods allow the creation of dynamic tests by returning a collection of TestInfo objects, enabling tests to be generated based on runtime conditions.

   Answer: D. JUnit 5 @TestFactory methods allow the creation of dynamic tests by returning a collection of TestInfo objects, enabling tests to be generated based on runtime conditions.

   JUnit 5 @TestFactory methods are designed for dynamically generating tests. They return a collection of TestInfo objects, which can be used to define test cases at runtime. This is useful for creating tests based on conditions that are not known until runtime, such as data from external sources or varying inputs. The other options are incorrect because they either describe features of other JUnit annotations or misrepresent the functionality of @TestFactory methods.

3. What is the correct description of how the @BeforeEach annotation works in JUnit 5?

   1. The @BeforeEach method is called once per test class, regardless of how many test methods are present.
   2. The @BeforeEach method is called once before all test methods in the same test class, initializing shared resources.
   3. The @BeforeEach method is called before each test method in the same test class, ensuring that each test starts with a clean state.
   4. The @BeforeEach method is called after each test method in the same test class, cleaning up resources.

   Answer: C. The @BeforeEach method is called before each test method in the same test class, ensuring that each test starts with a clean state.

   The @BeforeEach method is executed before each individual test method in the same test class. This ensures that each test starts with a clean and consistent state. It is not called before all tests in the class (which would be @BeforeAll), nor is it called after each test (which would be @AfterEach). It also does not run once per test class by default unless the class is annotated with @TestInstance(Lifecycle.PER_CLASS).

4. A developer is writing a test for a Spring Boot application, but the test is slow and not focused on the specific layer they want to test. What is the most likely issue with their test setup?

   1. The test is not using the @InjectMocks annotation to inject mocks into the class under test.
   2. The test is using @SpringBootTest instead of a slice annotation like @WebMvcTest or @DataJpaTest, which loads the full application context and is slower than necessary.
   3. The test is using the wrong version of Mockito, which is incompatible with JUnit 5.
   4. The test is missing the @MockitoBean annotation to mock dependencies properly.

   Answer: B. The test is using @SpringBootTest instead of a slice annotation like @WebMvcTest or @DataJpaTest, which loads the full application context and is slower than necessary.

   Using @SpringBootTest loads the entire application context, which is slow and unnecessary for most unit or integration tests. Instead, slice annotations like @WebMvcTest or @DataJpaTest should be used to load only the relevant parts of the application context, improving test speed and isolation.

5. Which approach is recommended for testing the data access layer in a Spring Boot application with performance and isolation in mind?

   1. Use @SpringBootTest with a real database and run tests in parallel.
   2. Use @WebMvcTest and mock all repository dependencies manually.
   3. Use @MockitoBean to replace the JPA repository with a mock and test the controller layer.
   4. Use @DataJpaTest with an embedded database and ensure each test is transactional and rolled back.

   Answer: D. Use @DataJpaTest with an embedded database and ensure each test is transactional and rolled back.

   When testing Spring Boot data access layers, @DataJpaTest is used to load only the JPA repositories and an embedded database. Each test is transactional and automatically rolled back to ensure tests are isolated and performant.