Тестирование, которое включает звонки на удаленные сервисы

Question

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

Кто-нибудь может посоветовать, как мне поступить?

Вот процесс:

Метод использует веб-сервис для создания объекта в удаленной системе. После создания сущность возвращается обратно в локальную систему посредством струйной подачи (это не является частью кода, подлежащего проверке). Затем тест должен выполнить запрос к локальной базе данных, чтобы убедиться, что объект был правильно создан. Сложность состоит в том, что время, необходимое для обновления локальной базы данных сущностью, является переменным.

Любые советы и предложения приветствуются.

Заранее спасибо.

Answer 1

Вы определенно проводите интеграционный тест. Это вполне выполнимо в JUnit, но вам всегда нужно знать, что именно вы тестируете, и что вы можете тестировать.

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

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

Итак, все, что вы можете проверить, - это то, что некоторые отправляемые вами данные окажутся в базе данных через некоторое время. Итак, чтобы проверить, что что-то происходит, все, что вам нужно сделать, это проверить, что соответствующая строка находится в базе данных. Это может быть просто SELECT COUNT(*) WHERE ... [*]

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

1. вам придется обновлять тест каждый раз при смене удаленного сервиса,
2. каждый раз, когда изменяется версия удаленной службы, вы должны добавлять логику в свои тесты.

Помните, что место для тестирования сложной логики приложения в удаленном сервисе находится в коде удаленного сервиса. Не твой код.

Еще одна вещь, которую нужно учитывать:

Когда кто-то тестирует чужой код, все может измениться без предупреждения, тесты могут провалиться без предупреждения из-за ошибок в их коде, неработающего сервера интеграции и неработающей базы данных. Если возможно, установите код на машине, которой вы управляете, это минимизирует количество проблем такого типа, которые у вас возникнут. Другая альтернатива - иметь отдельный проект. специально для этих тестов, поэтому, по крайней мере, ваши сборки будут работать, если эти тесты не пройдут.

Если у вас есть контроль над удаленным сервисом, отлично. Поместите свои сложные логические тесты в тесты для этой службы, и все, что вам нужно в локальном приложении, это проверить, возвращаются ли некоторые данные, тест на петлю.

Что касается самого теста, то, вероятно, будет достаточно простого вызова удаленной службы и затем цикла, который проверяет наличие данных каждые 5 секунд или около того. С таймаутом конечно. В JUnit нет ничего конкретного для цикла, но посмотрите на Timeout @Rule для Timeout.

[*] Наряду с соответствующими ошибочными условиями, конечно.

Answer 2

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

Хотите проверить, может ли механизм БД вставлять действительные значения?Надеюсь нет.Вам не нужно запрашивать базу данных для тестирования создания сущности.

Что вы должны проверить, так это то, может ли ваша логика правильно генерировать эти значения или, возможно, она может построить правильную INSERT командную строку.В этом случае зависимости от службы и реальных объектов, связанных с DAO / DB, должны быть faked .

В модульном тестировании вы хотите сосредоточиться на отдельном элементе (отсюда и название unit testing) одновременно.В этом случае я предполагаю, что это будет правильное создание сущности / значений.Тестирование всего процесса больше похоже на интеграционный тест .Это то, что вы хотели сделать?