Только начал изучать Mockito, и у меня есть метод, который сгенерирует код для последующего создания запроса и сохранения в базе данных.
Есть ли идеи, как проверить это с помощью @Mock, или мне это не нужно?
public String generateCode(byte[] input) {
return StringUtils.join(DigestUtils.sha1Hex(input).toUpperCase();
}
Не уверен, что я хорошо понимаю Mockito для такого метода ... Спасибо за любые предложения
@Autowired
RequestUtil requestUtil; // this is where generateCode method is
@Test
public void generateSuccesCode() {
requestUtil.generateCode(input);
}
Должен ли я создать некоторый byte [] до этого и перейти к параметру generateCode
Не уверен, как Mocking помогает мне в моем методе выше
StringUtils.join(DigestUtils.sha1Hex(input).toUpperCase();




Я не думаю, что вам здесь вообще нужно использовать Mockito.
Тестирование этого метода с реальным значением (и ожиданием, основанным на этом значении) простое и предлагает полное покрытие.
Например:
@Test
public void foo() {
RequestUtil requestUtil = new RequestUtil();
Assert.assertEquals("0BEEC7B5EA3F0FDBC95D0DD47F3C5BC275DA8A33", requestUtil.generateCode("foo".getBytes()));
}
Этот подход работает до тех пор, пока у вас есть некоторые ожидания относительно того, какой вывод является допустимым для данного ввода.
Если у вас есть такое ожидание, то все, что я предлагаю, - это передать значение и подтвердить, что ответ соответствует этому ожиданию.
Если, однако, у вас действительно есть ожидание нет того, какое значение должен вернуть generateCode(), и, следовательно, ваше единственное ожидание состоит в том, что он вызовет DigestUtils.sha1Hex() и передаст ответ через StringUtils.join(), тогда вам придется использовать PowerMock для имитации DigestUtils. Например:
@RunWith(PowerMockRunner.class)
@PrepareForTest({DigestUtils.class})
public class TestTest {
private RequestUtil sut = new RequestUtil();
@Test
public void testGenerateCode() {
PowerMockito.mockStatic(DigestUtils.class);
byte[] input = "anInput".getBytes();
final String hex = "0beec7";
Mockito.when(DigestUtils.sha1Hex(input)).thenReturn(hex);
String actual = sut.generateCode(input);
Assert.assertEquals(hex.toUpperCase(), actual);
}
}
FWIW, этот подход вводит сложность без каких-либо дополнительных преимуществ. Я не вижу веской причины для этого. Этот метод является детерминированным, поэтому я бы порекомендовал вам разрешить вашему тесту передать значение и утверждать, что метод всегда возвращает ожидаемый сгенерированный результат для этого значения.
Не уверен, что вставить в "foo" getBytes ()); часть, всегда получающая ожидаемую ошибку блока "0BEEC7B5EA3F0FDBC95D0DD47F3C5BC275DA8A33", например, и всегда получать было "сгенерирована некоторая случайная строка", как это сделать? Спасибо
Спасибо за предложения, я посмотрю, что я могу сделать с этим PowerMock, потому что я не ожидаю, какое значение должно вернуть generateCode (), он всегда генерирует случайную шестнадцатеричную строку
DigestUtils.sha1Hex() возвращает нет случайную строку. Его выход предсказуем и детерминирован для любого заданного входа.
Угадайте, что нет способа достичь ожидаемых и фактических значений в простом подходе JUnit ... попробую с PowerMock.
«Простой подход JUnit» является подход, который использует ожидаемое и фактическое значение. Первая часть моего ответа показывает утверждение для входа «foo», независимо от того, как часто вы вызываете Digest.sha1Hex() для «foo». GetBytes () ответ будет таким же, так что это пример использования известных входов + выходов для тестирования метод generateCode().
Согласитесь, еще раз спасибо, посмотрю, что я могу сделать с PowerMock.
Я обновил ответ, пытаясь прояснить, что я имел в виду под подходом «фактическое значение», а также предоставил пример имитации внутреннего устройства
generateCode()с помощью PowerMock.