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

add

#1

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

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

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

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


#2

Из гиттера:

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

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

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


#3

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

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

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

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

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


#4

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

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

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

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

Решение:

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

#5

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

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

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

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

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

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

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


#6

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

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

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

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

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

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

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


#7

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

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

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

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

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


#8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


#9

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


#10

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


#11

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


#12

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

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


#13

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


#14

по 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 оф”.

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