Повторение мокито в заглушке и проверке

Question

Похоже, что в некоторых случаях заглушка EasyMock может занять место проверки.Возьмите следующий тривиальный пример:

Класс A:

public class A {
    private B b;

    public A(B b) {
        this.b = b;
    }

    int main(int input) {
        return b.timesThree(input + 4);
    }
}

Класс B:

public class B {
    int timesThree(int input) {
        return input * 3;
    }
}

Класс ATest:

@ExtendWith(MockitoExtension.class)
public class ATest {
    @Mock
    B b;

    @InjectMocks
    A a;

    @Test
    void testMain() {
        doReturn(21).when(b).timesThree(7);

        int result = a.main(3);
        assertEquals(21, result);

        verify(b).timesThree(7);
    }

}

Есть литочка для вызова verify?Вызов when уже устанавливает входной параметр на b.timesThree(), равный 7.

Answer 1

В этом случае нет. Все сводится к тому, что вы действительно пытаетесь утверждать в тесте.

Здесь вы пытаетесь проверить, что когда основной метод вызывается со значением 2, должно происходить

1. timesThree следует вызывать со значением + 4

2. значение, возвращаемое из timesThree, должно быть возвращено вашей основной функцией

Поскольку в вашем тесте приведенных ниже трех строк достаточно для подтверждения обоих вышеупомянутых случаев, вам не нужно проверять здесь.

doReturn(21).when(b).timesThree(7);
int result = a.main(3);
assertEquals(21, result);

Самый простой способ выяснить, достаточно ли хорош ваш тест, - это закомментировать отдельные части вашей реализации и заставить ваш тест провалиться (TDD). Пока вы проходите неудачный тест, вы хороши.

Пример: изменить 4 на 5 - тест не пройден, удалить входной тест не пройден

Предположим, ваш метод timesThree не возвратил значение, а вместо этого сохранил его где-то

int main(int input) {
//Stores value somwhere
    b.timesThree(input + 4);
}

Здесь вы тестируете, чтобы утверждать, что timesThree вызывается один раз со значением 7. В этом случае вам нужна проверка, так как вы никогда не сможете пройти неудачный тест без проверки.

Также в примечании к одному из упомянутых комментариев «тест прошел бы, если бы код был заменен на return 21;»

Чтобы проверить ваш тест против этого, используйте случайное целое число вместо значений жесткого кодирования. Это обеспечит отсутствие случайного жесткого кодирования в вашей реализации. Пример библиотеки для случайных целых чисел https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/math/RandomUtils.html#nextInt()