Тестовый пример, полезность которого я не понимаю (взято из Плед):
Какой здесь смысл? С помощью этой строки вы уже говорите своей платформе возвращать предопределенный результат всякий раз, когда вызывается метод getUsers(), а затем вы проверяете, что он действительно возвращает предопределенный результат.
whenever(service.getUsers("111,222")).thenReturn(Response.success(users))
@Test
fun getUsers_withSuccess() = runBlocking {
// Given that the service responds with success
whenever(service.getUsers("111,222")).thenReturn(Response.success(users))
// When requesting the users
val result = dataSource.getUsers(listOf(111L, 222L))
// Then there's one request to the service
verify(service).getUsers("111,222")
// Then the correct set of users is returned
assertEquals(Result.Success(users), result)
}
Я вижу этот точный тестовый пример примерно так:
@Test
fun getUsers_withSuccess() = runBlocking {
val a = 4;
assertEquals(a, 4)
}
Чем эти два тестовых примера даже различны и как в случае Plaid проверяется что-нибудь полезное, я имею в виду, какую ошибку можно отловить с помощью этого тестового примера? Есть ли большая картина в этом тестовом примере, которую я упускаю?
Примечание: Насколько я понимаю, шаблон whenever {something} return предназначен для использования в очень редких случаях, но им злоупотребляют.





В данном случае тестируется метод getUsers для dataSource, а не метод getUsers для service.
Предполагается, что у метода dataSource.getUsers есть побочный эффект - он вызывает под капотом service.getUsers.
Этот тест проверяет 4 вещи:
service.getUsers на самом деле происходит, когда мы вызываем dataSource.getUsersdataSource.getUsers правильно преобразует свой входной параметр во входной параметр для service.getUsers (listOf(111L, 222L) в "111,222")
Да, дело в том, что это модульный тест, который имеет дело только с поведением одного компонента, в данном случае
dataSource. У этого компонента есть зависимость,service, но на самом деле вы не хотите задействовать реальный из них, потому что теперь ваш тест основан на поведении двух вещей (или более, в зависимости от того, с чем взаимодействуетservice). Таким образом, вместо этого тест имитирует объектservice, определяет конкретные действия, которые он должен делать во время этого теста, а затем проверяет, были ли все взаимодействия ожидаемыми. Это просто актер, играющий роль, если хочешь