Я предлагаю сделать следующее:
- модульные тесты / не должны попадать ни на один внешний ресурс
- целевые интеграционные тесты (я думаю, это будет снизу вверх).У вас должен быть код, очень близкий к внешнему ресурсу, и единственная ответственность за него заключается в его интеграции.Не пытайтесь проводить юнит-тестирование этих классов, вместо этого проводите очень целенаправленные тесты, которые воздействуют на реальный ресурс и не должны иметь дело с остальной логикой в вашей системе.Сохраняйте эти классы интеграции как можно более тонкими
- полными системными тестами (я думаю, большой взрыв).Я имею в виду интерфейс и все (или API, если это ваша конечная точка).Удостоверьтесь, что вы максимально охватили предыдущие тесты, и это больше похоже на простые проверки, соответствующие элементы подключены соответствующим образом.
В зависимости от вашей системы, вы можете или не хотите дополнять 3 с помощьюинтеграционные тесты на верхнем уровне кода, но без использования пользовательского интерфейса.Независимо от того, какой вариант вы выберете, убедитесь, что у вас есть более всесторонний охват с помощью модульных и целевых интеграционных тестов, поскольку тестирование различного поведения на верхнем уровне имеет уровень сложности, который очень быстро выходит из-под контроля.
Должны ли интеграционные тесты совпадать с юнит-тестами, означающими одинаковое количество тестов, но без тестов?Или эти тесты должны тестировать что-то совершенно другое?
Как я уже упоминал в 1 и 2, лучше всего, когда они тестируют разные вещи.Это зависит от системы, но обычно я ожидаю, что количество модульных тестов будет в несколько раз больше, чем интеграционных тестов.Для полных системных тестов убедитесь, что у вас достаточно, чтобы вы могли сказать, что все компоненты были правильно подключены, но не настолько, чтобы это становилось слишком сложным для тестирования каждого сценария.