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

Question

Допустим, я тестирую веб-сервис, и у меня есть несколько сценариев ios требует аутентификации пользователя:

Scenario #1: Customer sign-up

Scenario #2: Customer sign-in

Scenario #3: Customer change name

Scenario #4: Customer update image

Если все тесты go пройдут через все шаги входа в систему, как:

1) Go to register page
2) Enter new user information
3) Activate account
4) Go to login page
5) Enter login and password
6) Press the Login button
7) Check if I authenticated as a customer

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

Так что, если у меня есть такая конечная точка, это означает, что я могу пропустить повторное тестирование все время одни и те же вещи и просто короткие реализации ios # 3 и # 4. Но в этом случае у меня менее естественная среда.

Расскажите, пожалуйста, о лучших практиках , которые вы используете в реальных проектах.

Answer 1

Не следует копировать и вставлять сценарий «входа в систему» ​​во все другие сценарии ios, но наличие учетной записи и вход в систему являются необходимыми условиями для других случаев использования. С точки зрения поведения, ориентированного на поведение, это приведет к одному или нескольким Given шагам, которые имитируют или фактически выполняют эти шаги:

Scenario: Customer change name
    # Calls web service or database to create new user
    Given "Bob" is a registered user

    # Calls web service or database to make account active
    And "Bob" has an active account

    # Opens browser, navigates to login page, fills out login form and submits it
    And the user is logged in as "Bob"

    # Steps specific to changing name and asserting it has changed
    When the user changes their name to "Samuel"
    Then the user's name is "Samuel"

Answer 2

Несколько рекомендаций:

• используйте тестовую пирамиду integration> ui (тесты намного медленнее в пользовательском интерфейсе, автоматизируйте в пользовательском интерфейсе только необходимые вещи для охватить основные потоки)
• для пользовательского интерфейса используйте быстрые методы для настройки (так что да, веб-службы, тестовый вход в систему только один раз)
• , если возможно, сохраняйте некоторые тестовые данные в сборках (например, чтобы убедиться, что новая сборка, которая может изменить структуру данных, не влияет на базовые функции c, например, для входа в систему)
• тесты должны быть атомарными c (не зависящими друг от друга)
• do некоторая очистка время от времени, чтобы удалить дубликаты тестового кода и улучшить структуру (скорость, стабильность)