Тестирование API: Могу ли я уменьшить свои усилия по функциональному тестированию API, увеличив свои модульные тесты? Могу ли я заменить функциональный тест для модульного теста?

Question

Я пытаюсь оптимизировать свои усилия по тестированию API (как для остальных, так и для SOAP). Я думаю, один из способов сделать это - устранить лишние функциональные тесты. Я называю их избыточными, потому что те же тесты могут выполняться на уровне модульного тестирования.

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

Как этого добиться? Какова взаимосвязь между модульными тестами и функциональными тестами?

Давайте рассмотрим пример службы customerAccount / add. Скажем, если у меня есть 6 тестов, 2 положительных (счастливый путь) теста, 2 теста с превышением граничного значения, 1 тест для клиента не найден, 1 недействительный тест для клиента. Могу ли я исключить один из двух положительных тестов и один из двух тестов с «превышением граничного значения», если эти два теста проверены на уровне модульного тестирования? Итак, 2 теста пройдены на уровне модульных тестов, 4 - на уровне функционального тестирования.

Разработчики могут не тестировать сервисы на конечных точках, вместо этого они могут тестировать классы и методы. Но в приведенном выше примере мы все еще тестируем конечные точки. Так что это покрыто.

Что вы думаете об этом подходе?

Answer 1

Я согласен, что следует избегать лишних тестов. Но - что делает тесты излишними? Я считаю, что тест является избыточным, если все потенциальные ошибки, которые этот тест намеревается обнаружить, также должны быть обнаружены оставшимися тестами.

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

Под модульным тестированием понимаются те ошибки, которые вы можно найти, протестировав небольшие (даже минимально небольшие) отдельные части программного обеспечения. Так как модульное тестирование является самым ранним этапом тестирования, который также имеет шанс глубже проникнуть в код go, практическое правило заключается в том, что если ошибка может быть уже найдена при модульном тестировании, вы действительно должны найти ее с помощью модульного тестирования. вместо того, чтобы пытаться поймать эту ошибку в тестах более высокого уровня. Похоже, это соответствует вашему подходу к «устранению избыточных функциональных тестов», где «одни и те же тесты могут выполняться на уровне модульного тестирования». Например, если вы стремитесь найти потенциальные ошибки в случае арифметического переполнения c в некотором коде, это должно быть сделано именно с помощью модульного тестирования. Попытка найти ту же проблему на уровне интеграционного или подсистемного тестирования была бы неправильным подходом.

Однако вы должны знать, что, возможно, цель подсистемного теста (= функциональный тест) если у нас с тобой одна и та же терминология) был другой, чем похожий тест на уровне юнит-теста. На уровне подсистемы вы можете стремиться отлавливать ошибки интеграции, например, если объединены неправильные версии классов (в этом случае соответствующие модульные тесты каждого из классов могут пройти). Подсистемные тесты также могут обнаружить ошибки системы сборки, например, если сгенерированные классы для среды написанного вручную кода не сгенерированы должным образом. И т. Д.

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