Возможно, вам следует сделать шаг назад и сначала задать несколько вопросов.
- Какую самую важную часть испытать?
- Насколько сложно настроить этот тест?
- Стоит ли стоимость настройки теста, чтобы получить результаты теста?
- Могу ли я протестировать большую часть того, что я хотел, с помощью более простого теста?
В любом случае, я бы использовал прибор, основанный на реальных данных и ожидании того, какими будут эти данные. Это позволяет нашему тесту быть детерминированным и, следовательно, автоматизированным.
Если наиболее важная часть - это часть логики, которую можно проверить с помощью модульного теста с известными входами / выходами и имитациями.
Если тестирование интеграционной части действительно является наиболее важным, тогда я постараюсь найти баланс между макетированием как можно большего количества движущихся частей, насколько мне было удобно, чтобы сделать тест более управляемым.
Чем больше сетевых ресурсов вы используете, тем сложнее система и тем больше тестов она должна иметь. Вы должны подумать о проблемах синхронизации, времени безотказной работы, времени ожидания, состояниях ошибок и т. Д. Вы также можете попасть в ловушку создания теста, который не является детерминированным. Если ваше утверждение заканчивается поиском различий во времени, полагайтесь на определенные моменты времени или полагайтесь на ненадежную службу, которая ломает много; чем вы можете закончить с тестом, который бесполезен из-за количества «шума» от ложных положительных разрывов.
Если вы хотите использовать модель непрерывной интеграции, вам также необходимо учитывать сложности управления (запуск и завершение работы) или нескольких процессов при каждом запуске теста. В целом, вам легче управлять тестом, если вы можете сделать так, чтобы тест выполнялся одним процессом, а другие «процессы» были вызовами функций для соответствующих начальных точек в коде.