Какие виды тестовых объектов существуют в JUnit и их назначение

Что проверяют

Различаете ли вы две вещи, которые прячутся за словами «тестовые объекты»: устройство теста в самом JUnit и тестовых двойников, которыми подменяют зависимости. Следом почти всегда спрашивают, чем mock отличается от stub и когда проще написать fake руками.

Как отвечать

Уточните, о чём речь, и разберите обе стороны. Устройство теста в Jupiter API:

• тестовый класс и метод: метод помечается @Test, ни класс, ни метод не обязаны быть public. На каждый метод создаётся новый экземпляр класса, @TestInstance(Lifecycle.PER_CLASS) это меняет;
• фикстура: подготовка и уборка через @BeforeEach и @AfterEach, дорогая общая настройка через статические @BeforeAll и @AfterAll;
• параметризованный тест: @ParameterizedTest с источниками @ValueSource, @CsvSource, @MethodSource;
• группировка: @Nested для вложенных сценариев, @Tag для фильтрации, @Suite из junit-platform-suite;
• расширения: @ExtendWith, например MockitoExtension или расширение Spring.

Тестовые двойники по классификации из книги «xUnit Test Patterns»:

• dummy: заполняет параметр и не используется;
• stub: отдаёт заданный ответ, when(repo.find(id)).thenReturn(user);
• spy: реальный объект с частичной подменой и записью вызовов, spy();
• mock: по нему проверяют взаимодействие, verify(sender).send(any());
• fake: рабочая упрощённая реализация, например репозиторий на HashMap.

Исключения проверяйте через assertThrows: он возвращает исключение, и можно проверить сообщение.

Где спотыкаются

Отвечают аннотациями JUnit 4: @Before, @Test(expected = ...), @RunWith(Parameterized.class). В Jupiter они не работают без vintage-движка, и интервьюер слышит устаревший опыт.

Называют «моком» любой двойник и ставят verify на каждую зависимость. Такие тесты ломаются от рефакторинга, хотя поведение не менялось.

Делят состояние между тестами через статические поля. Порядок методов в JUnit намеренно неочевиден, а при параллельном запуске общий статик ломается окончательно.