DRY или DAMP - Какой из них эффективен в сценариях тестирования автоматизации API?

Question

В настоящее время я пишу сценарии тестирования автоматизации REST API. Поскольку большая часть исследовательской статьи предполагает, что мы должны написать DAMP (Описательные и осмысленные фразы) тесты, которые способствуют удобочитаемости. Тем не менее, я чувствую, что в моих тестах много повторяющихся кодов, и в попытке удалить дубликаты я получаю код «DRY» (не повторяйте себя), который имеет тенденцию к зависимости тесты. Так что я немного запутался, какой подход использовать? Буду очень признателен, если кто-нибудь может дать мне несколько советов по этому поводу?

Answer 1

Общее правило - хранить код, связанный с Целью теста DAMP , имея все остальное DRY. Чтобы упростить правило, код, связанный с целью тестирования , может ссылаться на:

• Действия, которые НАПРЯМУЮ влияют на ожидаемый результат

• Параметры данных, которые НАПРЯМУЮ влияют на ожидаемый результат

Код, НЕ связанный с Целью теста , может ссылаться на :

• Действия, которые не влияют на ожидаемый результат НАПРЯМУЮ (Пример: авторизация для тестов, не связанных с входом в систему)

• Данные конфигурации и параметры данных, которые не влияют на ожидаемые результаты ПРЯМО (Пример: базовый URL, логин и пароль для тестов, не связанных с авторизацией)

Answer 2

Мои рекомендации:

• повторное использование полезных нагрузок (JSON или XML) из файлов, где это возможно
• потоки входа, которые устанавливают заголовок Authorization должно быть многоразовым
• не объединять запросы API к различным конечным точкам в повторно используемое Scenario
• даже для одной и той же конечной точки, для очень разных полезных нагрузок (например, границы / условия ошибки) используйте отдельный Scenario для каждого
• используйте Scenario Outlines для тестов, управляемых данными

Также, пожалуйста, обратитесь к этому ответу для хорошего примера того, что НЕ следует делать : { ссылка }