Глядя на ваш код, я не могу понять, как вы могли бы смоделировать / заглушить Session или SessionFactory, поскольку ни одна из этих вещей не «внедряется» в класс SampleInsert.
Под «введенным» я подразумеваю, что значения не передаются в класс каким-либо образом, обычно это делается с помощью аннотации с такой средой, как Spring, или с помощью конструкторов.
Следует помнить, что мы не тестируем вещь, над которой мы издеваемся, мы заменяем вещь, которую мы высмеиваем, представлением, которое намного проще, чтобы протестировать компонент, который использует вещь издеваются.
В качестве примера того, как вы можете использовать Mockito:
public interface SomethingToMock {
int returnSomeValueFor(int value);
}
public class ToBeTested {
private SomethingToMock session;
public ToBeTested(SomethingToMock session) {
this.session = session;
}
public void methodToTestA(int value) {
returnSomeValueFor(value);
}
public int methodToTestB(int value) {
int i = returnSomeValueFor(value);
return i * i;
}
}
@RunWith(MockitoJUnitRunner.class)
public class SomeTests {
@Mock
private SomethingToMock aMock;
private ToBeTested underTest;
@Before
public void setUp() {
underTest = new ToBeTested(aMock);
}
@Test
public void testOne() {
underTest.MethodToTestA(3);
verify(aMock).returnSomeValueFor(3);
}
@Test
public void testTwo() {
when(aMock.returnSomeValueFor(3)).thenReturn(2);
int r = underTest.methodToTestB(3);
assertEqual(r, 4);
}
}
В приведенном выше примере мы создаем интерфейс, который представляет собой объект, который нужно смоделировать, мы должны стремиться только к тому, чтобы смоделировать интерфейсы и только те, которые мы или наша команда создали.
Затем у нас есть класс, который нам нужно протестировать, который использует интерфейс ToBeTested
, мы можем предположить, что конкретная реализация интерфейса тестируется в другом месте проекта.
ToBeTested
имеет два метода для тестирования, один из которых не имеет возврата, поэтому не имеет побочных эффектов, которые мы можем видеть. Второй метод выполняет некоторую обработку и имеет побочный эффект.
Затем мы создаем тестовый класс для тестирования обоих методов, мы гарантируем, что он настроен на использование Mockito (@RunWith(MockitoJUnitRunner.class
), затем мы настраиваем макет с помощью @Mock
, последний шаг установки - убедиться, что наш класс имеет макет " вводится "в него, это делается методом setUp()
.
Наконец, мы создаем два теста, первый из которых проверяет, что вызванный метод вызывается, нам не нужно устанавливать when
для этого в этом случае, так как никакое значение не будет возвращено из метода, который мы тестируем, только из Я считаю, что метод Mockito вернет значение по умолчанию для int.
Второй тест проверяет, что значение возвращено, поэтому мы устанавливаем when
, когда проверяемый метод вызывается способом, указанным в when
, возвращается заданное значение, и мы можем утверждать, что правильное значение возвращается из тестируемого метода, в этом случае с использованием assertThat
Это общая схема тестирования с помощью Mockito. Эффективное тестирование - огромная тема, я бы посоветовал вам сделать некоторые исследования в Интернете Документы Mockito и JUnit очень хороши, и, конечно, у GitHub есть много проектов, использующих оба; одна из идей может состоять в том, чтобы взглянуть на Mockito и Unit на Github и посмотреть на их тестирование.
Также документация Mockito очень хорошо объясняет, как, почему и когда использовать насмешку: http://static.javadoc.io/org.mockito/mockito-core/2.25.1/org/mockito/Mockito.html
Надеюсь, это поможет.