Как обрабатывать логин пользователей при использовании maxInstances для webdriverio

Question

Теперь я пытаюсь обновить maxInstances > 1 webdriverio для нашего теста автоматизации продукта, но я не могу найти хороший способ заставить разные экземпляры теста использовать разных пользователей для запуска теста. Иногда разные экземпляры будут использовать одного и того же пользователя для входа в систему, что приведет к таймауту первого сеанса экземпляра входа в систему.

Кто-нибудь знает, как заблокировать / разблокировать пользователя для такого сценария？

Answer 1

Позвольте мне сказать прямо: вы пытаетесь запустить несколько экземпляров, и у каждого из них появляются разные параметры, верно? (например: в вашем случае используйте разные, не конфликтующие учетные записи пользователей для запускаемых потоков ). Не кажется ли вам, что вы zugzwang 'себя?

---

Теоретически, каждый тест должен иметь следующие три характеристики:

• small
• атомный
• автономный

---

❒ Возможные решения:

1. Ожидание wdio-shared-store-service для проверки> утверждено> объединено> выпущено

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

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

---

Реорганизовать логику тестирования:

• иметь специальные тестовые учетные записи, связанные с конкретными проверками ( тестовые случаи ) внутри ваших файлов функций ( наборы тестов * 1045)*)
• Если вы хотите очень серьезно относиться к тому, что ваши проверки атомарные , то создайте каждую учетную запись пользователя для определенного набора тестов (, поскольку набор тестов будет выполняться тольков одном случае для каждого регрессионного прогона )
• организуйте свои тестовые наборы так, чтобы только определенные учетные записи пользователей использовались для конкретного прогона, и сделайте ваши прогоны конкретными: добавьте переключатель -suite к вашемукоманда

---

  suites: {
    user: [
      './test/features/user/AnalyticsChecks.js',
      './test/features/user/SitemapChecks.js'
    ],
    superuser: [
      './test/features/superuser/HeaderChecks.js',
      './test/features/superuser/FooterChecks.js'
    ],
    admin: [
      './test/features/admin/DropUserRoles.js',
      './test/features/admin/ClearCache.js'
    ],
    batman: [
      './i/am/the/Darkness.js'
    ],
  }

---

Создайте своих пользователей динамически ( предварительное тестирование или во время выполнения теста )

Если вам повезет и у вас есть доступ к некоторым внутренним вызовам, чтобы подтолкнуть пользователей с конкретными настройкамив БД ( Обратитесь за поддержкой к разработчикам Backend. Принесите им конфеты! ), затем создайте скрипт , который производит таких пользователей,

В качестве альтернативы, вы можете создать custom_command, который достигает того же. Вы вызываете свои before/beforeEach крючки.

! Примечание: Не забудьте убрать за собой в after/afterEach крючки.

Недостатки:

• противоречит принципу small
• вы не сможете запустить их против PRODUCTION
• вы, вероятно, будете отмечены вашим бэкэндом за постоянное загрязнение БДновые пользователи (, особенно если вы запускаете 3-5 полных регрессий в день * )

. Вы наверняка найдете решение, которое устранит это ограничение среды. Будь креативным. Все идет. Ура!