по BDD разрабатывать всегда одинаково
- собираем требования с заказчика
- пишем ожидаемую функциональность на языке Gherkin
- кодируем шаги проверки поведения, или переиспользуем уже готовые
- разрабатываем функциональность
- проверяем что запуск проверки поведения выдаем зеленый результат
@Dexius
Эти несколько шагов сделаны были больше для доказательства что библиотечные шаги вообще возможны, сделаны были Сашей Алехиным изначально (с) - дальше не развивались, по двум причинам
- мало было проектов с обычными формами - текущие выпуски релизов ADD показывают что такой проект сейчас идет - пошли доработки именно в неуправляемых формах. Поэтому здесь пошло движение
- вторая причина - нехватка свободного времени “Есть более приоритетные задачи”. На мне на этом спринте висит актуализация документации и приведение её в человекочитаемый вид и улучшение процесса сборки.
Подытожу - @Dexius задал простой вопрос только сформулировал странно, я его вопрос прочитал как
“Что-то маловато библиотечных шагов для неуправляемых форм”
Ответ тут простой - да именно так. Мало, очень мало.
И сейчас у меня нет прямой рекомендации - стоит ли тратить время/деньги на покрытие кода сценариями поведения и тестами неуправляемых форм и разработку библиотечных шагов или остановиться и подумать ? может стоит эти ресурсы потратить на миграцию на управляемые формы ? на конфигурацию с управляемыми формами. Будь моя воля как программиста - я бы вообще не стал работать с неуправляемыми формами кроме как с задачами по их выпиливанию.
Когда мы сейчас говорим про неуправляемые формы - чаще всего речь идет про УПП (есть исключения с БП 1.6 и УТ 10.3 - но их меньшинство)
Последние 3 года на проектах где присутствует УПП я всем рекомендую делать следующее:
- обратить внимание руководства что УПП почти труп (вендор продолжает лобировать выпиливание УПП из своего портфолио) и пора думать о миграции - не обязательно на ERP, а просто на конфигурации с управляемыми формами.
- руководство обычно посылает тебя нафиг с формулировками “нет ресурсов, обоснуй и т.д.”.
- изменяем архитектурный подход к реализации текущих задач называется “мышление рабочими столами”
- меняем режим использования интерфейса у конфигурации “8.2, режим Такси разрешить”
- при анализе поступающих требований на разработку выбираем требования которые можно реализовать в виде небольших рабочих столов - для операторов на складе, бухгалтеров разносящих выписки и т.д. - делаем тонкие клиенты для небольших ролей и потихоньку мигрируем пользователей на управляемые формы, подсистемки “тырим” из БСП и т.д.
- это функционал уже доступен для проверки с помощью 1С:ТестКлиент
На мой взгляд - с точки зрения ресурсов этот подход прозрачней и для руководства и для команды разработчиков.
Всем топящим за неуправляемые формы я обычно задаю вопрос - “А зачем вам делать неуправляемые формы качественней ?” “Чтобы что ?” - мы же знаем честный ответ верно ? чтобы ничего не менялось - все же хорошо было, а тут раз и трехвенка и какой-то то там 8.3.12 с О УЖАС системой видеозвонков внутри платформы ;-). Это же если мы смигрируем на новые формы - нас заставят это делать, а не хочется - а тут еще и футбол посмотреть надо.
Когда-то это уже было… Всё повторяется ;-). @kuntashov @artbear у вас не возникает аналогии с “прямыми запросами из 1С++” - как мы тогда злились что “только энтузиасты используют классы”, а остальные “гады такие” используют компоненту тольго для ускорения отчетов. “Предатели идей ООП” - сжечь их на костре
Ну а если серьезно - фичи из воздуха и автовидеоинструкция это то чего нет у Аслака ;-), поэтому это получилась и фишка и проклятье одновременно.
НО я вам открою секрет - только никому не говорите ;-). Наибольший эффект на проектах дают три команды
gitsync export
vrunner xunit smoke
vrunner syntax-check
deployka update uat
остальное уже тонкий тюннинг - BDD, TDD, Sonar это уже для ведущих разработчиков, обычный программист 1С с сертификатом по платформе отваливается на этапе той самой кнопконажималки. НО это не катастрофа - это просто НЕ желание быть инженером-программистом. Поэтому нечего навязывать. Что все эти люди будут делать с EDT ума не приложу. Но это будет лет через 10
Поэтому мы тут на данном этапе больше сосредоточены на развитие сборочной линии - обратите внимание: книга вышла именно по релиз-инженерии, а не про тесты или поведение.
P.S. А хотите я вам напомню https://youtu.be/pa4MXT4Cw1s
Мы уже это однажды обсуждали когда-то - tdd vs bdd, теперь “уф vs оф”.
Можно кстати практику архитектурных комитетов восстановить - но нужно коллективное согласие участвовать в организации.