Как разрабатывать в обычных формах по BDD?

Контекст: Обычные формы, запускаю ванессу чтобы написать фичу

Проблема: Я понимаю, что фичи из воздуха только для управляемых форм?
Нашел два шага из коробки проверка наличия элемента и клик по кнопке.

Как разрабатывать в обычных формах по BDD?

Автор: @Dexius
Источник: https://gitter.im/silverbulleters/vanessa-behavior?at=5b35191759799e70174a20c3

1 Симпатия

Из гиттера:

Alexander Kuntashov @kuntashov июнь 29 00:13

Как разрабатывать в обычных формах по BDD?

Если речь про end-to-end тестирование через UI с полноценной автоматизацией, то практически никак из-за особенностей реализации обычных форм.

@Dexius я не совсем согласен c @kuntashov - тестирование UI в обычных формах возможно.

Конечно, далеко не в таком объеме, как в УФ :frowning:

Можно протестить:

  • открытие и закрытие формы
  • нажатие кнопки на форме
  • проверить наличие реквизитов и их значения - через Форма.ЭлементыФормы (или .Элементы)
  • интерактивное редактирование/изменение значения реквизита в поле ввода

как видно, набор операций не так уж и мал :slight_smile:

А вообще для BDD на самом деле не такая уж большая разница - ОФ или УФ.

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

Приходится делать свои библиотеки используемых в ОФ-конфигурации шагов + часть реализаций мокать или подменять.

Например, есть задача - проверить, что пользователь видит определенные сообщения от системы в случае неверных действий.

Решение:

  • каждое использование Сообщить() и т.п. меняется на вызов собственного механизма - метод Сообщения.Вывести()
  • этот метод помимо показа сообщений складывает сообщения в спец.регистр - измерения Пользователь, Дата и ресурс Сообщение.
  • есть набор шагов теста, который читает последнее сообщения для текущего пользователя, и проверяет наличие нужных строк - аналогично шагам УФ
  • спец.регистр периодически чистится регл.заданием - раз в 1-2 часа

А вообще для BDD на самом деле не такая уж большая разница - ОФ или УФ.

Артур, не правда, большая разница, когда речь идет про инструментальную поддержку, а именно ее все имеют в виду, когда говорят “BDD”. И особенно, когда речь про стоимость владения такими сценариями.

Оценить размер задницы разницы можно сравнив количество библиотечных шагов для ОФ и УФ, например.

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

В реальности сейчас на ОФ сейчас на поддержке остались УПП и УТ с большим (очень большим) количеством legacy-кода, который писали не думая про необходимость его тестировать. Да даже если бы думали авторы доработок, об этом не думали авторы типовых УПП и УТ…

Поэтому, нет, не легко. Даже legacy с УФ совсем не так легко, как можно подумать, читая твои комментарии.

P.S. и OFF Ты как “продавец” продукта краткосрочную задачу “продать” такими заявлениями решишь, но это не очень хорошо с точки зрения долгосрочного глобального маркетинга продукта: завышенные ожидания часто превращаются в волну негатива (“о, Артур сказал, что в ОФ тестириовать по BDD также как УФ!” - “Блин, чтобы проверять ошибки в сообщениях, мне надо перелопатить всю конфигурацию, а потом еще эти 100500 внешних отчетов и обработок!”). Народ клюет, идет пробовать, думая, что все легко, а потом пишет “у SB мало документации”, т.к. то, что слышит и то, что реально видит, пытаясь сделать не соответствуют друг другу.

3 Симпатий

А вообще для BDD на самом деле не такая уж большая разница - ОФ или УФ.

я неточно сформулировал эту фразу.
Ее нужно читать, как с точки зрения методологии BDD написание шагов/сценариев методически не слишком отличается для ОФ и УФ.

Конечно, с точки зрения вложений и возможностей ОФ далеко позади УФ с его API-тестирования от 1С и от нашего сообщества.

Про legacy отдельная большая и больная тема.

УТ, УПП, ЗУП 2.5 и т.п. и т.д. еще вполне себе живы, и мы с ними сталкиваемся на внедрениях у Энтерпрайза.
И даже БП 1.6 и ее производные :slight_smile:

PS @kuntashov и все-таки я не продавец продукта, я один из его авторов и активных внедрятелей, и что важно, один из активнейших пользователей :slight_smile:

Напоминаю, что продукт бесплатен :slight_smile:

А тут вопрос детализации шагов и сценариев + повторное переиспользование.

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

Не забываем про желание пользователя “сделайте мне одну БААЛЬШУЮ кнопку для всего”.

Можно сделать любую абстракцию, но ее детализация все равно должна быть конкретной.

Например, в реальности для QA-тестировщика шаг выглядит как “Я вижу сообщение …”, а вот низом идет как раз приведенное мной решение.

и все-таки я не продавец продукта

“Продавать” не значит “брать за продукт деньги”, а “продвигать его использование”.

А вообще для BDD на самом деле не такая уж большая разница - ОФ или УФ.

Исходный вопрос был “Фичи из воздуха только для УФ? … Как правильно разрабатывать в ОФ по BDD?”

В очередной раз обращаю внимание на трагизм ситуации: BDD у 1Сников стало ассоциироваться с “фичами из воздуха” и накликиванием сценариев мышкой.

Буквально автор спрашивает “Как накликать сценарий для ОФ?”.
На что ты отвечаешь:

тестирование UI в обычных формах возможно.

А потом еще немного отдалившись от исходного вопроса вообще пространно говоришь, игнорируя, что автор поставил знак равно между BDD и “фичами из воздуха”:

А вообще для BDD на самом деле не такая уж большая разница - ОФ или УФ.

Так делают только опытные продаваны: плавно уходят от ответа конкретный вопрос в сторону рассуждения о гибкости методики и бесконечном потенциале продаваемого продукта.

Но, согласись, честный ответ такой:

  • фичи из воздуха для ОФ - никак
  • с некоторыми ограничениями и проблемами ОФ тестировать можно, но штатно в ADD (и в VB/VA) готовых шагов существенно меньше, чем для ОФ
  • ОФ автоматизированно тестировать существенно сложнее, чем УФ, т.к. нет штатной инструментальной поддержки тестирования на уровне платформы, нужно использовать сторонние кнопконажималки, типа Сикули, либо довольствоваться подходом 1С:Сценарного тестирования со всеми недостатками
  • не нужно путать методику BDD и инструменты, реализующие автоматизацию этой методики, т.к. эти инструменты можно использовать и не по методике BDD

Ну и плюс твой классный ответ про легаси и все остальное. Вот он как раз хорошо приземляет.

А тут вопрос детализации шагов и сценариев + повторное переиспользование.

Я не про отношение сценария и шагов его реализации, а про стоимость таких вот рефакторингов ради шагов для тестирования.

Тестировать ОФ технически можно, но в реальной ситуации (переписанные УПП/КА/УТ, которые доживают свой век) сложно, дорого и в связи с этим нецелесообразно. Иногда дешевле тестировать силами обезьянок, и это нормально.

4 Симпатий

Или тестировать не фичами, а старым добрым xUnit

@EvilBeaver да, такая опция тоже есть, в том числе и для тестирования UI при помощи тех же сикулей.

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

Все что угодно, лишь бы на картошку не ездить поведение не описывать.

Вот согласен на 100%
Кнопконажималки - не от хорошей жизни же :slight_smile:

1 Симпатия

Уже превратилось в катастрофу. Где-то пора вывесить большое жирное VB != BDD.

1 Симпатия

по BDD разрабатывать всегда одинаково

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

@Dexius

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

  • мало было проектов с обычными формами - текущие выпуски релизов ADD показывают что такой проект сейчас идет - пошли доработки именно в неуправляемых формах. Поэтому здесь пошло движение
  • вторая причина - нехватка свободного времени “Есть более приоритетные задачи”. На мне на этом спринте висит актуализация документации и приведение её в человекочитаемый вид и улучшение процесса сборки.

Подытожу - @Dexius задал простой вопрос только сформулировал странно, я его вопрос прочитал как

“Что-то маловато библиотечных шагов для неуправляемых форм”

Ответ тут простой - да именно так. Мало, очень мало.

И сейчас у меня нет прямой рекомендации - стоит ли тратить время/деньги на покрытие кода сценариями поведения и тестами неуправляемых форм и разработку библиотечных шагов или остановиться и подумать ? может стоит эти ресурсы потратить на миграцию на управляемые формы ? на конфигурацию с управляемыми формами. Будь моя воля как программиста - я бы вообще не стал работать с неуправляемыми формами кроме как с задачами по их выпиливанию.

Когда мы сейчас говорим про неуправляемые формы - чаще всего речь идет про УПП (есть исключения с БП 1.6 и УТ 10.3 - но их меньшинство)

Последние 3 года на проектах где присутствует УПП я всем рекомендую делать следующее:

  1. обратить внимание руководства что УПП почти труп :wink: (вендор продолжает лобировать выпиливание УПП из своего портфолио) и пора думать о миграции - не обязательно на ERP, а просто на конфигурации с управляемыми формами.
  2. руководство обычно посылает тебя нафиг с формулировками “нет ресурсов, обоснуй и т.д.”.
  3. изменяем архитектурный подход к реализации текущих задач называется “мышление рабочими столами”
  4. меняем режим использования интерфейса у конфигурации “8.2, режим Такси разрешить”
  5. при анализе поступающих требований на разработку выбираем требования которые можно реализовать в виде небольших рабочих столов - для операторов на складе, бухгалтеров разносящих выписки и т.д. - делаем тонкие клиенты для небольших ролей и потихоньку мигрируем пользователей на управляемые формы, подсистемки “тырим” из БСП и т.д.
  6. это функционал уже доступен для проверки с помощью 1С:ТестКлиент

На мой взгляд - с точки зрения ресурсов этот подход прозрачней и для руководства и для команды разработчиков.

Всем топящим за неуправляемые формы я обычно задаю вопрос - “А зачем вам делать неуправляемые формы качественней ?” “Чтобы что ?” - мы же знаем честный ответ верно ? чтобы ничего не менялось - все же хорошо было, а тут раз и трехвенка :wink: и какой-то то там 8.3.12 с О УЖАС системой видеозвонков внутри платформы ;-). Это же если мы смигрируем на новые формы - нас заставят это делать, а не хочется - а тут еще и футбол посмотреть надо.

Когда-то это уже было… Всё повторяется ;-). @kuntashov @artbear у вас не возникает аналогии с “прямыми запросами из 1С++” - как мы тогда злились что “только энтузиасты используют классы”, а остальные “гады такие” используют компоненту тольго для ускорения отчетов. “Предатели идей ООП” - сжечь их на костре :wink:

Ну а если серьезно - фичи из воздуха и автовидеоинструкция это то чего нет у Аслака ;-), поэтому это получилась и фишка и проклятье одновременно.

НО я вам открою секрет - только никому не говорите ;-). Наибольший эффект на проектах дают три команды

gitsync export
vrunner xunit smoke
vrunner syntax-check
deployka update uat

остальное уже тонкий тюннинг - BDD, TDD, Sonar это уже для ведущих разработчиков, обычный программист 1С с сертификатом по платформе отваливается на этапе той самой кнопконажималки. НО это не катастрофа - это просто НЕ желание быть инженером-программистом. Поэтому нечего навязывать. Что все эти люди будут делать с EDT ума не приложу. Но это будет лет через 10 :wink:

Поэтому мы тут на данном этапе больше сосредоточены на развитие сборочной линии - обратите внимание: книга вышла именно по релиз-инженерии, а не про тесты или поведение.

P.S. А хотите я вам напомню https://youtu.be/pa4MXT4Cw1s

Мы уже это однажды обсуждали когда-то - tdd vs bdd, теперь “уф vs оф”.

Можно кстати практику архитектурных комитетов восстановить - но нужно коллективное согласие участвовать в организации.

6 Симпатий