Запуск/закрытие TestClient'а

#1

Всем привет!

Практически во всех сценариях приходится использовать шаг я открыл новый сеанс TestClient или подключил уже существующий.

Это технический шаг. Почему бы не заменить его тэгом “@RunTestClient”?

Это бы сделало сценарии более читаемыми.

Сеанс клиента тестирования как принято закрывать, когда сценарий выполнен?

Вообще меня сильно смущает после codeception/behat, что очень много технических вещей, не относящихся к тестируемому прикладному поведению, принято в ADD/VA реализовывать в виде шагов.

1 Симпатия
#2

Интересное предложение по тегу.
Но тогда этот тег превращается в техническую деталь :wink:
И на самом деле указанный шаг не всегда выполняется.
Часто выполняются другие шаги подключения тест-клиентов, например, под нужным бизнес-пользователем, а не пользователем-админом.

Задумайся, не слишком ли часто твои бизнес-сценарии выполняются под админом :wink:

АДД сама может закрывать тест-клиенты при включенной настройке.

#3

Тэги для этого и задумывались, поэтому у них специальный синтаксис.

С этим все ок, я стараюсь соблюдать принцип “один сценарий = одна роль”. Это вне контекста 1С, с BDD в 1С у меня пока опыт не очень большой, но в веб-разработке какой-никакой есть.

У тега можно задавать параметры. Можно роль брать из юзер-стори (Я как <Роль>...) и автоматически использовать нужного пользователя.

#4

При интерактивном запуске из bddRunner’а есть возможность указать, чтобы после выполнения последнего шага клиент закрывался?

#5

Да, есть флаг “закрывать тест клиенты после прохождения всех сценариев”. Точное название не помню, но в параметрах я его почти всегда указываю

#6

Использую релиз ADD 5.6.0, хоть убейте, не вижу этого флага в форме.

Зато по коду вижу, что настройка ЗавершитьРаботуСистемы используется только в клиентском методе ЗапускВРежимеКоманднойСтроки(), и реквизит формы НадоЗавершитьРаботуСистемыПослеВыполненияВсехСценариев на форму не выведен.

Ладно, пока не критично.

#7

В specflow есть классная штука. Называется хуки для всего проекта тестирования можно в хук [BeforeScenario] вынести необходимые технические вещи. Причем делать это в зависимости от тегов.
Подробнее тут: https://specflow.org/documentation/Hooks/ https://specflow.org/documentation/scoped-bindings/
Если бы в плеере такое было - можно было бы шаг открытия тестклиента вынести туда и в зависимости от тега подставлять туда нужную роль.

Ну или еще такая штука как target: https://specflow.org/plus/documentation/Targets/
Мы в зависимости от тегов запускали прогон одной и той же фичи в разных браузерах с разным разрешением.

действительно, в шагах много технической информации. Клиентов от этого testclienta уже плющит ))

1 Симпатия
#8

Это ты другой флаг нашёл. Тот, про который я говорю, имеет “testclient” в имени.

#9

Да, я тоже в codeception в события before/after все прячу, согласен,что хотелось бы и в ADD аналогичную возможность иметь.

1 Симпатия
#10

Сделаю еще один заход, но по “testclient” в первую очередь искал.

#11

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

Т.е. before/after читают/пишут разработчики, а текст фич читают и меняют не только они, но и пользователи с меньшим ИТ-скиллом.

Плюс также часто получается вариант, когда before/after часто приходится добавлять неуниверсальные шаги, которые являются уникальными для текущей фичи.

В итоге такой вариант становится плохо сопровождаемым, часто прячет значимые=важные детали поведения и т.п.

Вариант с тегами очень интересен, думаю над ним.

и я к варианту с before/after отношусь с большой опаской.

#12

И почему это аргумент “против”?

Я как раз и говорю, что технические шаги вида “Я запускаю TestClient” или вот эти твои новые полезные шаги Полезные шаги по быстрому переходу к формам загружаемых объектов “пользователям с меньшим ИТ-скилом” вообще не понятны и в тексте фичи их быть не должно.

Подчеркну, что я говорю про ADD не как про инструмент для создания и выполнения приемочных end-to-end тестов программистами, программирующими на геркине.

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

  • написать фичу для пользователя, согласовать
  • переписать на “ADD-Геркин”

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

Это бред, если честно.

В BDD cценарии должны быть максимально независимы от реализации, у Алексея был где-то репо с переводом статьи про “идеальный сценарий”, там хорошо все это было написано.

2 Симпатий
#13

это не технический шаг. он просто странный)
Сценарий же должен выполняться от какой-то роли, а не от кого угодно.
Правильнее поменять формулировку на что-то типа: Я как “Роль такая-то” запускаю 1с.
тогда и прятать ничего не надо и всем понятно.

А если в таком шаге уже в зависимости от тегов в “beforescenatio” менять роли. таким образом можно будет один сценарий прогнать под несколькими ролями.

#14

Согласен. Пользователю не понятно, что такое за режим запуска TestClient, поэтому я и называю его техническим.

#15

так есть жеж:
И я подключаю TestClient “ИмяКлиента” логин “Пользователь1” пароль “1”
просто переформулировать его правильно надо.

1 Симпатия