В настоящее время я работаю в крупной известной компании в нашей команде инструментов тестирования и фреймворков. Так что, хотя я и не эксперт, это часть моей работы. Я собираюсь говорить конкретно о веб-тестировании. Тестирование несколько отличается для нативных приложений, таких как iOS и Android, и я не очень знаком с этими аспектами.
Терминология между e2e (сквозное) и интеграционными тестами несколько взаимозаменяема, в то время как модульные тесты имеют более конкретное определение.
Как правило, e2e / интеграционные тесты должны выполняться в среде разработки и производства. В зависимости от ваших настроек, ваша среда разработки, вероятно, использует частично обновленный снимок вашей производственной базы данных. В других случаях ваша локальная среда может достигать фактического уровня производства. У обоих подходов есть свои плюсы и минусы, но это во многом зависит от масштаба вашей компании или проекта. Например, если вы работаете в большой компании с выделенными командами, вы можете наблюдать множество изменений в день, затрагивающих производственные базы данных по сравнению с небольшой командой, где еженедельный снимок prod db, вероятно, достаточно хорош для локального тестирования.
я
На базовом уровне все интеграционные тесты должны рассматриваться как реальные. При работе с веб-приложениями необходимо учитывать множество других факторов, таких как различные веб-браузеры, сетевая активность / доступность и т. Д. Поэтому вывод данных для вызовов API позволит провести супер быстрое тестирование, но затем добавляет еще один уровень сложности. с проверкой актуальности макетов в реальной базе данных.
Запуск интеграционных тестов локально должен более или менее делать то же самое с вашим сервером разработки, что и с подготовкой и производством. За исключением того, что приложение определяет, работает ли оно в среде разработки, промежуточной или производственной среде для переключения URL-адресов и различных учетных данных, ожидается, что приложение будет вести себя точно так же.
Что касается вашего вопроса об аутентификации, ответ - да. Давайте посмотрим на 2 примера, которые показывают разные соображения.
Предположим, ваш проект очень маленький. Вы создаете несколько реальных учетных записей на производстве, и ваша база данных снимается еженедельно для использования в вашей локальной среде разработки. Вы просто запускаете интеграционные тесты с одним или несколькими из этих пользователей по мере необходимости. Поскольку локальные тесты влияют только на вашу локальную базу данных, вам не нужно беспокоиться о генерируемых данных, поскольку они не повлияют на производительность. Другие инженеры в вашей команде могут использовать тех же пользователей и не беспокоиться об этом. Если один инженер вносит некоторые изменения в схему БД, ORM и т. Д., То все просто получают новую копию снимка БД и продолжают работать.
Теперь для другой крайности. Предположим, ваш проект очень большой. Миллионы пользователей и сотни сотрудников коллективно вносят изменения в базу кода и базы данных каждый день. Существует множество способов настройки инфраструктуры для решения различных инженерных задач. Слишком много данных, и база данных слишком часто меняется, чтобы сделать возможным использование локальных снимков. В этом масштабе вы, вероятно, выполняете непрерывную интеграцию и запускаете тесты при каждом коммите. Вы хотите сделать это так, чтобы входящие изменения не вносились в производство и не вызывали серьезных проблем. Вероятно, вы используете локальные среды разработки для постоянно обновляемой промежуточной базы данных или даже для самой производственной базы данных. (Попробуйте спланировать промежуточную базу данных, так как это позволит избежать многих других проблем.)
Теперь наличие небольшого набора выделенных тестовых пользователей становится проблемой. Тесты проводятся постоянно, как автоматизированные, так и десятки инженеров, которые работают над своими собственными задачами. Поскольку промежуточная база данных, вероятно, является общей, вы можете легко начать получать странные конфликты, поскольку один и тот же пользователь-тестер делает все, что угодно, и начинает вызывать сбой тестирования. Хорошее решение, которое я видел для этого, является своего рода тестовым сервером проверки учетных записей. Вы создаете, скажем, 100 или 1000 (или более) тестовых учетных записей пользователей. Когда ваши интеграционные тесты запускаются, они буквально извлекают тестовую учетную запись пользователя с сервера. Когда тесты завершены, интеграционные тесты очищают все изменения, внесенные в этого пользователя, и сообщают серверу проверки, что пользователь снова свободен. Затем он случайно проверяется кем-то / чем-то другим, и цикл продолжается.
Итак, подробности, которые непосредственно связаны с вашим вопросом:
- У вас всегда должны быть выделенные тестовые учетные записи пользователей, точно такие же, как у обычных учетных записей, только выделенные для тестирования.
- В зависимости от масштаба команды и проекта, если небольшой, то подойдет несколько выделенных учетных записей. Если вы работаете в гораздо большем масштабе, вам нужно гораздо больше выделенных тестовых учетных записей и, возможно, вам нужна автоматизированная служба, которая позволяет отдельным прогонам тестов извлекать пользователей по мере необходимости.
- Тесты всегда должны убирать за собой. Если тест создает TODO, который сохраняется в БД. Когда тест завершен, этот TODO должен быть удален из БД. Если вы не уверены в этом, вы в конечном итоге столкнетесь с ошибками и проблемами, когда данные противоречивы. Не дай Бог, это произойдет на производстве.
- Беспокойство касается только данных о подделке для модульных тестов, если только вы не работаете в очень хорошей и специализированной инженерной среде, где у вас есть люди, преданные делу постоянного обновления макетов db. Если вы можете сделать это, ваши интеграционные тесты будут очень быстрыми, и вам не нужно будет особо беспокоиться о вещах с БД. Но это трудно поддерживать со временем без специальной поддержки.