BDD 1С по душе

Размышляя над проблемой тестирования, а точнее над проблемой качества решений, умные и не очень люди, в основном ломают копья над следующим противоречием “надо тестировать, но надо разрабатывать, а не тестировать” (Алексей Лустин) www.silverbulleters.org

                Изначально я планировал сделать обзор сразу двух техник разработки — TDD и BDD. Но прочитав статью Дена Норта – «Введение в BDD», я решил BDD рассмотреть подробней. В качестве словаря, предлагаю использовать глоссарий, который собрал из статей на www.wikipedia.org и www.habrahabr.ru.

                Начнем с аббревиатуры  «DD» (driven development). Алексей Лустин (технический директор компании «Серебряная пуля», которая специализируется на IT продуктах для бизнеса) хорошо охарактеризовал понятие «Разработка через» (driven development) в одной из своих статей на www.habrahabr.ru :

«Размышляя над проблемой тестирования, а точнее над проблемой качества решений, умные и не очень люди, в основном ломают копья над следующим противоречием “надо тестировать, но надо разрабатывать, а не тестировать”. Всё становится еще хуже, когда к этому мы добавим еще огромное количество подходов к проектированию и разработке. Например, как это классифицирую я, когда мне необходимо объяснить сущность проблемы:

Domain DDспособ разработки, когда цель заказчика сформулирована в виде базовых сущностей будущей системы: “Хочу Товары, Инвентаризацию, Акты списаний и оприходований”

Report DDспособ разработки, когда цель заказчика формулируется в виде конечных отчетов с анализом данных: “Хочу отчет о прибылях и убытках”

User Interface DDспособ разработки, когда цель заказчика сформулирована в виде конечного пользовательского интерфейса: “Хочу вот такую формочку для сотрудника на проходной по выдаче пропусков”

Behavior DDспособ разработки, когда цель заказчика сформулирована в виде конечного процесса ожидаемого в системе, или даже группы взаимосвязанных процессов: “Когда мы фиксируем отправку машины из Москвы, тогда нужно чтобы изменился статус заказа и зафиксировалось время отправки, а также надо учесть косвенные затраты на перевозку в себестоимости заказа”.

Отдельно стоит выделить еще 3 подхода, которые обычно нигде не описываются:

Sabotage DD способ разработки, когда цель заказчика формулируется в виде ускоренных сроков требующих разработки напрямую в Production системах: “Срочно добавьте на форму реквизит Булево =Ромашка=”. Применяется при попытках заказчика построить управляемый хаос в команде разработки — используется в политических целях.

Moratorium DDспособ разработки, когда цель заказчика не в запуске функциональности, а в соблюдении регламентов и нормативов утвержденных на предприятии: “Любое изменение в системе должны быть согласовано с <ЛистСогласования>, любые работы по проектированию, разработке и прототипированию не могут быть проведены без указания проекта и его технико-экономического обоснования”.

Pain DDпереходный способ разработки, когда цель заказчика повысить качество решений, не снижая сроков выхода функциональности: “Хочу чтобы вы производили всестороннее тестирование, но кстати не забудьте первого числа запуск системы WMS, не дай бог вам сорвать сроки. Да и кстати ФОТ нам в этом году урезали — выделенных тестировщиков не получите”.

Классификация конечно топорная и очень уж приземленная, но для подготовки специалиста к чтению умных книг по этому поводу, достаточная. (Алексей Лустин)

В этом списке нет Test DD и вот почему. В TDD нам не интересно, каким образом заказчик сформулировал свои требования, важно как мы будем контролировать выполнение нашего программного кода. Разберем пример: написан программный код, который формирует определенную таблицу с данными. У каждой колонки этой таблицы есть определенный тип данных, в каждой строке заполнены конкретные значения. Если мы допустим ошибку и в момент добавления строки в таблицу вызовем метод который класс таблицы не поддерживает, то такой код не пройдет синтаксис контроль или в процессе выполнения мы получим исключительную ситуацию. Но если мы какие-то поля в строке не заполним данными, это не будет являться ошибкой синтаксиса. Это может являться ошибкой логики. Тогда мы можем дополнить наш код конструкциями типа «Если Не ЗначениеЗаполнено() Тогда ВызватьИсключение()» и тем самым реализуем контроль логики кода. А теперь представьте, что сначала вы пишете код, который проверяет наличие в конкретной переменной «объекта таблицы» (таблицы еще может и не существовать), проверяете, что в этой таблице есть строки, что в этих строках заполнены значения и только потом вы начинаете писать код, который создает таблицу, заполняет строки и тд. В общих чертах — это и есть техника TDD.

                Теперь вернемся к BDD, и почему я решил подробней рассмотреть именно этот подход. Первая причина — если верить Дэну Норту, который не один год использовал TDD, то данная техника имеет серьезные недостатки, в ней нет конкретики. У тех кто начинает использовать эту технику сразу возникают вопросы: Проверять только передаваемые параметры и возвращаемые значения или весь код напичкивать конструкциями «if — then»? Сколько таких конструкций должно быть и как их классифицировать? В процессе использования данной техники Ден Норт встречался с большим количеством тупиковых ситуаций, которые разрулить не удалось до сих пор. К примеру, где гарантия того, что пройдя тесты ТDD мы получаем работоспособное приложение с точки зрения пользователя?

                Вторая причина – BDD является развитием TDD и содержит все ее преимущества и практически лишена ее недостатков. Сводная таблица ниже иллюстрирует сравнение техник BDD и TDD:

TDD

BDD

Написание кода тестов до написания кода программы

ДА

ДА

Прямая связь кода с требованиями с помощью Gherkin

НЕТ

ДА

Сценарное тестирование через интерфейс пользователя

НЕТ

ДА

Повторное использование кода тестов в других сценариях

НЕТ

ДА

                Эта таблица из лекции «Магия BDD» Леонид Паутов (ведущий разработчик компании «Серебряная пуля»), текст которой опубликован на www.infostart.ru . Я решил начать именно с этой таблицы, потому что в ней указаны не только отличия TDD и BDD но и основные решаемые задачи. Первый пункт «Написание кода тестов до написания кода программы» мы поверхностно рассмотрели два абзаца выше, но применительно к TDD. Как данная задача решается в BDD, мы поймем после разбора языка Gherkin.

Прямая связь кода с требованиями с помощью Gherkin

(За основу взята статья «Writing Features — Gherkin Language» с сайта www.behat.org)

Gherkin — это человеко-читаемый язык для описания поведения системы, который использует отступы чтобы задать структуру документа, (пробелы или символы табуляции). Каждая строчка начинается с одного из ключевых слов и описывает один из шагов. Основное преимущество — тесты могут быть разработаны не обязательно тестировщиками, а людьми которые вообще могут не знать программирования, например бизнес-аналитиками. Также это позволяет показать заказчику какой функционал был покрыт тестами. После получения файла со сценариями тестирования, тестировщику остается закрепить за каждой строкой необходимый код (об этом поговорим позднее).

                Ключевые слова в Gherkin: Функционал(Feature), Сценарий(Scenario), Дано(Given), Когда(When), Тогда(Then), И(And), Но(But), Сценарий-Схема(ScenarioOutline), Фон(Background), Образцы(Examples).

                Вспомогательные выражения в Gherkin: Чтобы(In order to), Как(As a), Хочу(I want to).

Истории выглядят примерно так:

Функционал[Краткое описание]

Чтобы [Получаемый результат]

Как [Потребитель результата]

Хочу [Функционал]

Сценарий: #1 [Описание]

Дано: [Ситуация или условие] или [Ситуация или условие]

И: [Ситуация или условие] или [Ситуация или условие]

Когда: [Событие или действие] или [Событие или действие]

И: [Событие или действие] или [Событие или действие]

Тогда: [Проверка результата] или [Проверка результата]

И: [Проверка результата] или [Проверка результата]

Сценарий: #N…

Пример:

Функционал: Распределение поступающей оплаты по документам реализации и зачет аванса контрагента.

Чтобы: Получить корректные проводки по счетам.

Как: Бухгалтер организации.

Хочу: При фиксации оплаты от контрагента, оплату отражать как аванс.

Сценарий #1: Поступает сумма оплаты от контрагента. Долг у контрагента, на момент оплаты, отсутствует (реализаций нет).

Дано: Контрагент (покупатель) «Иванов А.В.» оплачивает сумму 1000 рублей. Долг у контрагента отсутствует.

Когда: Фиксируется оплата от контрагента «Иванов А.В.» по договору «Основной» на сумму 1000 рублей.

Тогда: Формируется проводка по счету «АвансыПолученные» на сумму 1000 рублей.

Сценарий #2 Долг у контрагента, на момент оплаты, присутствует (есть реализации). Поступает сумма оплаты превышающая долг контрагента.

Дано: Контрагент (покупатель) «Иванов А.В.» оплачивает сумму 1000 рублей. Долг контрагента 500 рублей.

Когда: Фиксируется оплата от контрагента «Иванов А.В.» по договору «Основной» на сумму 1000 рублей

Тогда: Формируется проводка по счету «ВзаиморасчетыСКонтрагентами» на сумму 500 рублей (погашение долга)

И: Формируется проводка по счету «АвансыПолученные» на сумму 500 рублей (фиксируется аванс).

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

Чтобы: Получить корректные проводки по счетам.

Как: Бухгалтер организации.

Хочу: При фиксации оплаты от контрагента, чтобы оплата отражалась как аванс.

                Так же можно заменить, что в языке нет ключевого слово «или», поэтому текст ниже является ошибкой:

Дано: Контрагент (покупатель) «Иванов А.В.» оплачивает сумму 1000 рублей. Долг контрагента 500 рублей.

Или: Контрагент (покупатель) «Иванов А.В.» оплачивает сумму 500 рублей. Долг контрагента отсутствует.

                Вообще, слово «или» желательно избегать даже по тексту после двоеточия, так как это вносит определенную неоднозначность в сценарий. Но иногда этого избежать невозможно.

                Что касается таких ключевых слов как Фон(Background), Сценарий-Схема(ScenarioOutline) и Образцы(Examples) то их используют достаточно редко, особенно если код пишет не программист, а бизнес-аналитик.

                Теперь речь пойдет о связывании кода на языке Gherkin c реальным программным кодом. Это можно представить в виде таблицы:

Сценарий #2 Долг у контрагента, на момент оплаты, присутствует (есть реализации). Поступает сумма оплаты превышающая долг контрагента.

Код Gherkin(Дано, Когда, Тогда, И)

Код 1С (имена вызываемых процедур)

Дано: Контрагент (покупатель) «Иванов А.В.» оплачивает сумму 1000 рублей. Долг контрагента 500 рублей.

ПроверитьНаличиеДолгаКонтрагентаПоВзаиморасчетам();

Когда: Фиксируется оплата от контрагента «Иванов А.В.» по договору «Основной» на сумму 1000 рублей

СоздатьПровестиДокументПКО();

Тогда: Формируется проводка по счету «ВзаиморасчетыСКонтрагентами» на сумму 500 рублей (погашение долга)

ПроверитьПроводкиПоСчетамВзаиморасчетов();

И: Формируется проводка по счету «АвансыПолученные» на сумму 500 рублей (фиксируется аванс).

ПроверитьПоводкиПоСчетамАвансовКонтрагентов();

                Каждой строке кода на языке Gherkin сопоставляется одна процедура на языке 1С. Сразу должны возникнуть вопросы. Почему только одна процедура и зачем вообще, что то связывать?

                Что бы ответить на этот вопрос, давайте вернемся к первому пункту таблицы сравнения BDD и TDD.

Написание кода тестов до написания кода программы в BDD.

                Как я уже упоминал, концепция написания кода тестов до написания кода программы в ВDD, реализована немного иначе, чем в TDD. В Test Driven Development, для нас важно только проверить логику программного кода, а в Вehavior Driven Development важно проверить конечные процессы в системе (хотя параллельно проверять логику кода никто не мешает). Данные процессы, как уже известно, описываются с помощью Gherkin. В технике BDD это неотъемлемая часть написания теста, а так же формулирования требований, написания документации и тд.

                Но тесты на языке Gherkin невозможно выполнить, это не язык программирования. Но зато их можно связать с кодом на языке программирования. Важно чтобы эта была реальная связь, то есть код на Gherkin должен полностью соответствовать коду на реальном языке программирования. Чем детальнее эта связь (чем больше строк в коде Gherkin), тем более развернутым получается тест. Теперь о том, зачем нам развернутый тест.

                Основных причины две, первая: «В любом месте реального кода программы может возникнуть ошибка, и мы должны быстро понять — где и почему». Представим, что мы сделали следующую связь:

Сценарий #2 Долг у контрагента, на момент оплаты, присутствует (есть реализации). Поступает сумма оплаты превышающая долг контрагента.

Код Gherkin(Дано, Когда, Тогда, И)

Код 1С (имена вызываемых процедур)

Дано: Контрагент (покупатель) «Иванов А.В.» оплачивает сумму 1000 рублей. Долг контрагента 500 рублей.

ВыполнитьТест();

Когда: Фиксируется оплата от контрагента «Иванов А.В.» по договору «Основной» на сумму 1000 рублей

Тогда: Формируется проводка по счету «ВзаиморасчетыСКонтрагентами» на сумму 500 рублей (погашение долга)

И: Формируется проводка по счету «АвансыПолученные» на сумму 500 рублей (фиксируется аванс).

                Если у нас возникнет ошибка в процедуре ВыполнитьТест(), то мы как программисты найдем причину. Но нам, скорее всего, понадобится анализ кода, запуск отладчика и тд. А все это наше время. Другое дело, если ошибка возникнет в процедуре «ПроверитьПоводкиПоСчетамАвансовКонтрагентов()», которая сопоставлена в строке Gherkin «И: Формируется проводка по счету «АвансыПолученные» на сумму 500 рублей (фиксируется аванс).». Скорее всего, мы просто заглянем в движения документа и увидим там другую сумму или вообще отсутствие проводок.

                Вторая причина, и самая важная: «Мы планируем писать тест до написания программы». И выглядит это следующим образом: у нас уже есть логика на Gherkin, у нас уже есть имена процедур: ПроверитьНаличиеДолгаКонтрагентаПоВзаиморасчетам(), СоздатьПровестиДокументПКО(). Нам остается только зайти в «тело» одноименных процедур и написать там код. Конечно часть процедур нам может не понадобиться в реальной программе. Например «ПроверитьПроводкиПоСчетам() будет нагружать систему, да и если с проводками будет проблема, скорее всего бухгалтер это заметит. А вот другие процедуры, которые будут создавать и проводить документы, мы реально можем использовать. Причем, мы их поместим в общие модули, эти модули отнесем к соответствующим подсистемам и будем вызывать так же, как вызываем их в тестах. Красота и порядок.

                Теперь давайте разберемся какие процедуры, с какими строками связывать. В начале раздела, посвященного синтаксису языка Gherkin, указан шаблон истории. Связь реального кода осуществляется только со строками, в которых указаны ключевые слова: «Дано, Когда, Тогда» и детализируются связи с помощью ключевого слова «И».

                Напротив ключевого слова «Дано» в квадратных скобках указано «[Ситуация или условие]». Это значит, что на этом этапе проверяются параметры, выполняются запросы к базе данных, сравниваются значения. Это необходимые условия, которые должны быть уже выполнены до начала расчета и создания данных в информационной системе.

                Напротив ключевого слова «Когда» в квадратных скобках указано «[Событие или действие]». Это непосредственно расчет и создание данных.

                И наконец, напротив ключевого слова «Тогда» в квадратных скобках указано «[Проверка результата]». Это такие же проверки, как и после слова «Дано», только проверяем мы то, что было сделано после ключевого слова «Когда».

Сценарное тестирование через интерфейс пользователя

                Сценарное тестирование — это тестирование по предварительно написанному сценарию. Код на языке Gherkin это сценарий, а также отчасти документация и требования.

                Но только отчасти, потому что читая такую документацию, пользователь может застрять на первом же «Когда: Фиксируется оплата от контрагента «Иванов А.В.» по договору «Основной» на сумму 1000 рублей». Конечно, эту строку можно развернуть подробнее:

Когда: Создается документ ПКО

И: заполняется реквизит контрагент

И: Заполняется реквизит договор…

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

                Приведу еще пример: В документе ПКО, в модуле формы, в обработчике «ПриИзмененииКонтрагента()» есть проверка, что данный контрагент является физлицом. Такие проверки желательно делать перед записью в модуле объекта, но реальный процесс разработки может диктовать иное. Коля и Вася в какой-то момент времени одновременно дорабатывали один и тот же документ, модуль объекта был захвачен Колей, а Васе нужно было срочно доделать работу. Или задача стояла таким образом: «Выбираемое значение должно проверяться сразу». В результате наш тест этого вообще не выявит, потому что мы создаем документ ПКО программно, не открывая его форму. Мы можем при написании теста программно открывать форму и вообще эмулировать все действия реального пользователя, но объем кода в тесте увеличится в разы. Мы подошли вплотную к проблеме «надо тестировать, но надо разрабатывать, а не тестировать».

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

                Основная цель таких продуктов – это ускорить и упорядочить процесс написания тестов. Этот процесс должен стать максимально прозрачным и простым. В сфере автоматизации тестирования через графический интерфейс, можно выделить два основных вида инструментов:

  1. Которые взаимодействуют с интерфейсом приложения на уровне программного кода. Это выглядит примерно так же, если бы мы писали код открывающий формы и нажимающий кнопки, только у нас были бы генераторы этого кода. Мы бы нажимали на кнопку «Ок», а в модуле появлялась строка типа ТекущаяФорма.Кнопки.Ок.Нажать(). Но для того чтобы реализовать данную возможность, разработчик приложения должен заранее задуматься о предоставлении такого интерфейса.
  2. Которые взаимодействуют с интерфейсом через драйвера устройств ввода данных и используют механизмы распознания изображений. Это выглядит примерно так: программа ищет на экране конкретное изображение, если она его находит, то эмулирует клики мышки в конкретную область изображения и начитает ввод данных с клавиатуры. Данный подход не зависит от того, предоставил ли разработчик приложения такую возможность или нет. Но недостатком является то, что могут возникать ошибки при распознавании изображений, есть зависимость от разрешения экрана (оно должно быть неизменным) и скорость работы таких тестов ниже, так как на распознавание изображений уходит определенное время.

               Первый вид инструментов, на мой взгляд, самый перспективный. И если говорить об 1С, то начиная с платформы 8.3, разработчики предоставили нам такую возможность. Описание данного механизма, можно посмотреть на сайте 1С или http:// /news/автоматизированное-тестирование-в-1с-8-3/ . Но основная проблема, на сегодняшний день, это поддержка только управляемых форм. Данное условие является серьезным камнем преткновения для тех, кто использует конфигурации на обычных формах. Но не является безвыходной проблемой.

               В поисках решения я обратился ко второму виду инструментов, которые имеют общепринятое название «Image-based testing». Здесь оказался хороший выбор от навороченных и дорогих, типа «TestComplete», до простых и полностью бесплатных типа «SikuliX». Многие из этих продуктов сами имеют программный интерфейс, начиная от взаимодействия через командную строку, до встроенных интерпретаторов типа «Python». Основная идея для искателей решений данной проблемы, это обеспечить взаимодействие этих продуктов с платформой 1С, чем я уже занялся и в ближайшее время надеюсь предоставить результаты. Так же надеюсь, что возможно кто-то это уже сделал и поделится своими идеями.

               Ну а если для вас управляемый интерфейс это родное или вы уже придумали как быстро взаимодействовать с обычными формами, обратите внимание на продукт под названием «Vanessa Behavior». Он бесплатный и очень быстро развивается. Есть хороший видео обзор https://www.youtube.com/watch?v=KbImzcrj_58.

Повторное использование кода тестов в других сценариях

                Данный пункт – это высший пилотаж, но к нему по любому приходят все, кто всерьез занимается автоматизацией тестирования. Основная идея – использовать этапы одного теста в других тестах. То есть мы собираем некую библиотеку, в которой хранятся часто используемые действия, скажем по созданию и заполнению конкретных видов документов, формированию отчетов, проверке движений и тд.

                Опять же, если говорить о готовых решениях, то в «Vanessa Behavior» это тоже реализовано. На мой взгляд, данный проект весьма перспективен и заслуживает поддержки.

                Всем спасибо за внимание!

Глоссарий

Software development methodology (SDM) – Так же известны как software development life cycle, software development process, software process. Методологии деления процесса разработки программного обеспечения на отдельные фазы или этапы, каждый из которых содержит меры улучшающие планирование и управление процессом разработки в целом. В качестве примеров можно привести: «Каскадную модель» (waterfall model), Прототипное программирование (prototyping), СпираL9;льная модель (spiral model), быстрая разработка приложений(rapid application development), экстемальное программирование (extreme programming), различные agile-методы (agile methodology) и тд. (Wikipedia)

Agile software development. — Гибкая методология разработки (agile-методы)— серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности «экстремальное программирование», «DSDM», «Scrum», «FDD». (Wikipedia)

Driven Development (DD) (разработка “через” или разработка “от цели”) — один из способов организации процесса разработки в инженерии программного обеспечения. Входит в SDM (software development methodology) en.wikipedia.org/wiki/Software_development_process в виде отдельных методологий.

Domain-driven design (DDD).

Предметно — ориентированное проектирование. Это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом. Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. Это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс проектирования программного обеспечения в незнакомой предметной области. Есть книга — Эрик Эванс (Eric Evans) «Проблемно-ориентированное проектирование». (Wikipedia)

                Способ разработки, когда цель заказчика сформулирована в виде базовых сущностей будущей системы: “Хочу Товары, Инвентаризацию, Акты списаний и оприходований”(Алексей Лустин «Habrahabr.ru»)

Feature-driven development (FDD). – Разработка управляемая функциональностью. Итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки. (Wikipedia)

Testdriven development (TDD). – Разработка через тестирование. Техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (inspires confidence). В 1999 году при своём появлении разработка через тестирование была тесно связана с концепцией «сначала тест» (test-first), применяемой в «экстремальном программировании» (agile методология), однако позже выделилась как независимая методология. (Wikipedia)

behavior-driven development (BDD). — Разработка основанная на функционировании. Процесс разработки программного обеспечения, который возник из TDD. Объединяет главные техники и принципы TDD, идеи из DDD и OOAD (техника объектно ориентированного анализа и проектирования). BDD главным образом является идеологией о том, как разработке программного обеспечения быть одновременно понятной бизнесу и техническим специалистам. В ней используются специализированные программные инструментарии для разработки программного обеспечения. И не смотря на то, что эти инструментарии используются в основном в BDD проектах, они так же могут быть использованы для поддержки TDD. (Wikipedia)

                Способ разработки, когда цель заказчика сформулирована в виде конечного процесса ожидаемого в системе, или даже группы взаимосвязанных процессов: “Когда мы фиксируем отправку машины из Москвы, тогда нужно чтобы изменился статус заказа и зафиксировалось время отправки, а также надо учесть косвенные затраты на перевозку в себестоимости заказа”. (Алексей Лустин «Habrahabr.ru»)

Domain Specific language (DSL). Предметно-специфичный язык — язык программирования, специализированный для конкретной области применения, является ключевым понятием языково-ориентированного программирования. Любой новый язык в мире (будь-то PHP, ruby, python, Erlang, LISP, Closure или 1С) изначально создавался в качестве ответа на проблему. То есть если вы серьезно собираетесь изучать какой-либо язык или «фреймворк», вам необходимо вспомнить, «для чего» автор его создавал, вспомнить, что «не нравилось» автору в других платформах. (Алексей Лустин «Habrahabr.ru»)

44 Comments

  1. fishca

    Странное ощущение оставляет статья, какая-то она «википедичная». Есть какая-то недосказанность что-ли…

    Reply
  2. brr

    Кто в теме тот нового не узнал, но тему нужно продвигать в массы всеми силами, поэтому + за публикацию, автор пиши ещё.

    Reply
  3. dima_tuzov

    (1) Основная цель статьи — заинтересовать. Насчет недосказанности, значит возникли вопросы?

    Reply
  4. v3rter

    А с ГОСТами ( http://it-gost.ru/content/view/101/51/ ) планируется какая-нибудь стыковка?

    Reply
  5. dima_tuzov

    (4) ГОСТ 19.201-78 от 1980 и 34.602-89 от 1990 (Государственный стандарт союза ССР)? Какая стыковка? Вы о чем?

    Reply
  6. ture

    (5) Да, давайте как-то научней рассматривать подобные вопросы, т.к. здесь далеко не все дураки.

    Reply
  7. dima_tuzov

    (4) Ок. Как вы себе представляете стыковку Agile-методов с ГОСТами? Я себе не представляю…

    Reply
  8. JohnyDeath

    (7) Наверное в этом и был вопрос.

    Заказчик требует ТЗ по ГОСТу. Вы хотите от него Геркина, сценариев и Agile.

    Как быть? Бросать клиента? Писать Гибкое ТЗ?

    Reply
  9. dima_tuzov

    Я воспринимаю ТЗ по ГОСТу, как формальность. Представьте, что на этапе постановки задачи, вы ведете переговоры с заказчиком и конспектируете это в виде Gherkin. Вам это будет удобнее, чем писать какую-то прозу с абзацами и пунктами. Появится дополнительная информация по заданию, вам такую нотацию будет легче исправить, добавить группу «И» в «Когда», исправить пару «И» в «Тогда»… это ваш инструмент, не обязательно ему обучать заказчика.

    Заказчик требует от вас ТЗ, а вы получили все ответы на вопросы? Всем известно, сколько таких вопросов возникает уже в процессе программирования. Неожиданно поняли, что БП кривой.. Нельзя проводить этот документ не создав тот.. а вот тут вообще нужен был новый справочник… и тд…

    Когда вы пишите на Gherkin, вы по сути уже начали программировать и очень много начинает всплывать. А если сразу задумаетесь о связи Gherkin с кодом (как это уже было описано), вы сможете реально оценить время, которое уйдет на кодинг. Что после этого стоит написать ТЗ по ГОСТу?

    Reply
  10. grumagargler

    (9) можете привести реальный пример технического задания написанного на языке геркин? Желательно, чтобы это ТЗ лежало в основе проекта стоимостью скажем несколько десятков $К, утверждено заказчиком, и было выполнено качественно и в срок.

    Спасибо.

    Reply
  11. JohnyDeath

    (9) я хорошо представляю, что такое Gherkin и BDD. Но я также понимаю, что проект не будет утвержден только по набору фич.

    А есть заказчики, где ГОСТ — далеко не формальность, а обязательность (госструктуры, ВПК…)

    Reply
  12. fishca

    (3) недосказанность имеется ввиду с вашей стороны, чувствуется какая незавершенность статьи.

    Reply
  13. dima_tuzov

    (12) Я понял, такое ощущение у большинства, кто раньше не сталкивался с BDD. Формулируйте вопросы, будем общаться.

    Reply
  14. dima_tuzov

    (10) Реальные примеры приводят Алексей Лустин и Леонид Паутов (Ссылки в статье).

    Reply
  15. dima_tuzov

    (11) Почему вы противопоставляете понятие формальности и обязательности? Понятное дело, что ТЗ будут требовать и вам придется его писать… Вам предлагается инструмент, который поможет вам это сделать корректно и в короткий срок.

    Reply
  16. ture

    (15) — Почему вообще понадобились такие инструменты?

    — Потому что мирок программиста 1С перестал ограничиваться парой функций из букваря.

    — И что?

    — Программисты стали путаться в паре сосен.

    — Да, ну?!

    — API 1С стало не эффективным и приходится выискивать «правильный» путь. Каждый находит свой, а потом не понимает чужой код. В результате качество снижается и будет снижаться, если не остановить.

    — И что такого Вы предлагаете? Построить разработку задом на перед?

    — Да, нет! Просто поговорить хотелось.

    Reply
  17. pumbaE

    (16) Эх, опять сосны виноваты.

    Reply
  18. dima_tuzov

    (16) Критиковать BDD, да и вообще Agile-методы можно только попробовав их использовать на практике. Если у вас есть такая практика, поделитесь….

    Reply
  19. fishca

    (13) Вы ничего не поняли, у меня по этой теме вообще нет вопросов, мне все понятно. Материалы серебряной пули изучены вдоль и поперек. BDD — бесспорно вещь нужная, но ей надо заниматься и не все понимают эффект от применения этой технологии. Нет инструментов от вендора, а это многих отпугивает.

    Reply
  20. ture

    (18) Я не критикую, я не вижу в нем толка. Я считаю, что необходимость в такой терминологии отпадает вместе с детскими мечтами об идеале. В действительности есть причины и их прячут за новыми терминами.

    — Однако придется читать чужой код и тратить на это 90% времени.

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

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

    Еще немного 1ц подрастет и перестанет быть средой быстрой разработки ПО. Питон?

    Reply
  21. dima_tuzov

    Коллеги, давайте договоримся. Те кто толк в BDD не видят, сюда не пишут. А кто изучил вопрос вдоль и поперек, помогите раскрыть тему и убрать «недосказанности» из статьи. Есть вещи о которых я не написал, или написал недостаточно для понимания сути — жду вопросы. Не надо писать типа — и что дальше? или — как то все криво… Давайте по существу — я попробовал вот это, у меня не получилось вот то…

    Reply
  22. pumbaE

    (21) просто все ожидают увидеть магию в этих процедурах:

    ПроверитьНаличиеДолгаКонтрагентаПоВзаиморасчетам();
    СоздатьПровестиДокументПКО();
    ПроверитьПроводкиПоСчетамВзаиморасчетов();
    ПроверитьПоводкиПоСчетамАвансовКонтрагентов();

    а магии там нет.

    Reply
  23. kuntashov

    (21)

    помогите раскрыть тему и убрать «недосказанности» из статьи

    Тему бы вы раскрыли, если бы привели примеры из вашей практики, вот ровно вот как вы сами призываете — «я попробовал вот это».

    А так данная публикация — больше похожа на школьный реферат на тему «Что такое BDD» — нарезали цитат из известных публикаций и скомпоновали их.

    Reply
  24. ture

    (21) Помню как в прежние времена люди болели сервисной шиной и так мозг мой этим надрывали, что тошнило одни и те же слова слушать. Теперь вот долбят мозг тестированием. В тот раз им вручили инструмент, который полностью удовлетворял всем требованиям, даже написан на джаве. Увидели и отвернулись, теперь даже вспоминать не хотят.

    Reply
  25. MGraf

    (23)

    у бы вы раскрыли, если бы привели примеры из вашей практики, вот ровно вот как вы сами призываете — «я попробовал вот это».

    А так данная публикация — больше похожа на школьный реферат на тему «Что такое BDD» — нарезали цитат из известных публикаций и скомпоновали их.

    Вот у меня например практики почти нет. Сейчас я ищу варианты получения максимальной пользы от тестирования на всех проектах при минимальных затратах единожды. Пока только вот что придумал:

    1) Дымовые тесты после обновления нетиповой конфигурации

    2) Дымовые тесты для внешних печатных форм, обработок и отчетов каждый день.

    Трудозатрат ноль, а полезный эффект получаешь сразу.

    Reply
  26. grumagargler

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

    Reply
  27. dima_tuzov

    (23) Ок. Пример будет. Выложу отдельной статьей, как продолжение к реферату…

    Reply
  28. v3rter

    < инженеры | программисты | менеджеры | логисты | руководители среднего звена >

    отворачиваются от технологий как раз по причине излишней их пропаганды

    // )

    Reply
  29. 1ceo_2015

    Что касается таких ключевых слов как Фон(Background), Сценарий-Схема(Scenario-Outline) и Образцы(Examples) то их используют достаточно редко, особенно если код пишет не программист, а бизнес-аналитик.

    (0) а как вы повторности использования добиваетесь при редком употреблении данных слов?

    Reply
  30. nixel

    (29) интересно, откуда вообще возник такой перевод.

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

    https://github.com/cucumber/gherkin/blob/master/gherkin-languages.json

    И там есть Контекст, Структура сценария и Примеры.

    Reply
  31. Ndochp

    (25) «Тестирования нет, забудьте это слово» (С) Лустин.

    Ну и то, что вы привели это ТДД, а не разу не БДД 😉

    (0) Как мне надоели ребята, которые говорят, что БДД круче ТДД по определению (на самом деле потому, что после). Аж выть хочется.

    Итак, задача:

    УПП, при установленной галке «списывать спецодежду в НУ одновременно с БУ» при наличии нескольких видов спецодежды в эксплуатации при возврате спецодежды из эксплуатации формируется временная разница, а быть ее не должно.

    Разработка проверки по ТДД

    0. Подготовка справочников

    1. КЗР на некий «срез» регистра «Учет движения МПЗ и затрат Регл»

    2. программно формируем документ возврата из эксплуатации, проводим и проверяем отсутствие ВР

    3. Чистим за собой КЗР и возврат из эксплуатации (по вкусу — на нулевом шаге создаем, на этом чистим справочники)

    Разработка проверки по БДД

    А. Период -1:

    1. Оприходовать спецодежду нескольких видов на 10.10

    2. Сформировать документ передачи в эксплуатацию

    3. Сформировать документы закрытия периода (расчет себестоимости, по вкусу НУ)

    Б: Период 0:

    4. Сформировать документ по погашению стоимости материалов в эксплуатации

    5. Сформировать какой-нибудь выпуск, чтобы не тащить незавершенку в целевой период

    6. Сформировать документы закрытия периода (расчет себестоимости, по вкусу НУ)

    В: Целевой период

    7. Оформить возврат из эксплуатации, проверить отсутствие ВР.

    Когда нужно обновлять тест (когда он сломается)?

    ТДД — когда изменится:

    1. КЗР (никогда),

    2. структура регистра Учет затрат Регл

    3. документ возврат из эксплуатации (причем не форма, а внутре)

    БДД — когда изменится:

    1. Оприходование

    2. передача в эксплуатацию

    3. Отчет производства за смену

    4. Расчет себестоимости

    5. Погашение стоимости материалов в эксплуатации

    6. Возврат из эксплуатации

    Какой тест быстрее отработает на «ночной сборке» тоже в целом понятно.

    Reply
  32. 1ceo_2015

    (30) ну это уже второй вопрос))

    Reply
  33. kuntashov

    (31) Спасибо за реальный пример (поставил плюс именно за него).

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

    И когда сравнивают теплое с мягким у меня тоже начинается батхерт. Попробую его направить в позитивное русло.

    Оба ваших «подхода» можно реализовать и в виде модульного теста, и на Gherkin’е и по BDD.

    Поскольку про юнит-тесты вам все понятно, я напишу только про геркин.

    Геркин — не значит «прокликивание» мышкой и приемочные тесты с высокой степенью детализации, хотя я догадываюсь, откуда у вас такие впечатления.

    Как вы сформулировали задачу:

    УПП, при установленной галке «списывать спецодежду в НУ одновременно с БУ» при наличии нескольких видов спецодежды в эксплуатации при возврате спецодежды из эксплуатации формируется временная разница, а быть ее не должно.

    В геркин это «переводим» дословно:

    Сценарий: Ошибочное формирование ВР при возврате спецодежды
    
    Допустим, в ИБ в настройках установлен флаг «списывать спецодежду в НУ одновременно с БУ»
    И на остатках есть спецодежда нескольких видов
    
    Когда я оформляю документ «Возврат спецодежды из эксплуатации»
    Тогда не должно образовываться временной разницы
    

    Показать

    Когда вам пользователь рассказывал условие, наверняка он еще примеры привел в базе, которые по возможности в том или ином виде

    нужно в сценарии отразить (только значимое). Но это надо сделать и для модульного теста, как он без данных-то!

    Ну а реализацию шагов вы уже написали. Вот те, которые идут в «Допустим»:


    0. Подготовка справочников

    1. КЗР на некий «срез» регистра «Учет движения МПЗ и затрат Регл»

    и вот реализация шагов, которые идут в после «Когда» и «Тогда»:


    2. программно формируем документ возврата из эксплуатации, проводим и проверяем отсутствие ВР

    Зачистка данных — это служебное действие.

    Reply
  34. artbear

    (31) ИМХО ты также сильно утрируешь 🙂 как и приводимые тобой «ребята, которые говорят, что БДД круче ТДД по определению» 🙁

    Reply
  35. dima_tuzov

    (30) Спасибо за ссылку, сразу не нашел.

    Reply
  36. dima_tuzov

    (33) «Геркин — не значит «прокликивание» мышкой и приемочные тесты с высокой степенью детализации, хотя я догадываюсь, откуда у вас такие впечатления.» — вот это кстати очень похоже на реальность. А откуда это утверждение? Ссылка на «авторитетный» источник есть?

    Reply
  37. kuntashov

    (36) Да потому что это очевидный вывод, который вы сами сделаете, если будете изучать BDD не только по материалам от команды «Серебряная Пуля», а в том числе и на основе первоисточников, в частности, https://cucumber.io

    При всем уважении к Алексею и Леониду, большой акцент на крайне детализированные сценарии, которые преимущественно все про «прокликивание» (знаменитые «фичи и воздуха» и иже с ними) сыграли плохую шутку: геркин среди 1Сников стал рассматриваться как альтернатива записи кода для тестированию интерфейса.

    А такой подход нарушает один важный постулат BDD:

    Your cucumber features should drive your implementation, not reflect it.

    (с) https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool

    С этой статьи рекомендую и начать.

    Reply
  38. grumagargler

    Ребята, подскажите пожалуйста, а какую проблему решает огурец? Я понимаю, что с его помощью делается, я не понимаю какая при этом проблема решается. Если говорить о нашем домене, мне кажется гораздо эффективней разработчика отправить на курсы бухгалтерского учета, или бизнес аналитиков заставить сдавать 1С:Профессионал, чем использовать предлагаемые инструменты (я отдаю себе отчет в том, что там миллионы скачиваний). Но если аналитик не может донести проблему, или у разработчика отсутствует чувство задачи – то эти вопросы решаются другим образом, не инструментарием, на мой взгляд. На своей практике, выращивание в программисте чувства задачи идет другим путем, а конечные результаты – это понимание процессов с полуслова, постановка задачи в виде описания решаемой проблемы в нескольких предложениях на родном языке понятном конечному пользователю. Это не теория, а собственная практика, либо мне невероятно везет последние лет 15. Но вот из раза в раз подтверждается один простой тезис – если нет понимания конечной цели, никакой формализацией, включая языки описания поведения – осчастливить клиента не получится.

    Формирование документации на основе сценариев…простите, но такая документация бесполезна. Может быть это еще как-то можно назвать инструкцией, но никак не документацией.

    Reply
  39. kuntashov

    (38) Не думаю, что что-то новое вам открою, но все же…

    Пользователь и разработчик в процессе коммуникаций должны в идеале достичь общего понимания требований. Естественно, это понимание требований надо каким-то образом «зафиксировать» на понятным и тому и другому языке, с конкретными примерами данных.

    При должной формализации языка изложения требований, проверку их реализации можно автоматизировать.

    Таким образом ответить на ваш вопрос «какая проблема решается» можно так: геркин — понятный не-программисту, но при этом формальный (подходящий для автоматизации) язык для документирования требований к ПО, а огурец — инструмент для автоматизации проверки выполнения этих требований.

    А вообще, то что вы написали в (38) почти слово-в-слово говорил автор огурца Aslak Hellesøy — коммуникации первичны. Инструменты — геркины, огурцы и прочее — все это пустое, если понимание не достигнуто.

    Reply
  40. Ndochp

    (34) Ну так КЗР это же в чистом виде «тестирование реализации вместо тестирования поведения», не?

    Она же должна быть в БДД предана анафеме?

    Reply
  41. nixel

    (40) погодите.

    КЗР в случае бдд — это подготовка базы, секция контекст. Поведение у нас живет в Когда и Тогда, а в Дано по факту хоть прямыми запросами в базу пишите.

    Reply
  42. lustin

    (37) мы же это обсуждали и не раз. Я даже видео публичные записывал

    «В 1С мире развитие идет наоборот»

    первоисточник нужно читать в конце, а не в начале ;-).

    Развитие бехавойриста в 1С идет по следующему сценарию

    Фаза 1 — «Тестов нет, есть поведение»

    * фичи из воздуха — аналог Silenium

    * автодокументация — аналог PicklesUI

    * интегральные сценарии — аналог SpecLog, cucumber.pro

    * библиотеки шагов — аналог canned steps

    * сервер сборок — аналог cucumber-jvm-reports, allure-behavior

    Фаза 2 — «Тесты есть, но они зависимы»

    * поведение объектов

    * поведение общих модулей

    Фаза 3 — «Не всегда нужно BDD»

    * xUnitFor1C 😉

    в соседнем мире (а Аслака в частности) всё происходит наоборот по мере накопления «фич»

    * xunit

    * rspec

    * cucumber

    * canned-steps

    * silenium

    у нас же в 1С мире — фич сразу много, потому как большая часть функциональности формируется самой платформой.

    поэтому любой «бехайворист» 5 уровня, читает первоисточники по BDD начиная с фазы 3, но если он начнет это делать на фазе 1 — проверено, не напишет ни одной фичи и будет в G+ всех убеждать что BDD не нужен, TDD слишком избыточно в 1С и вообще «я буду жить как раньше»

    P.S. Обратите внимание — некоторые достигшие дзена, вдруг внезапно вычисляют что первоисточник то BDD как бы не Аслак и Мэт из команды cucumber.io, а внезапно Дэн Норт… И даже делают перевод его статей (за что Денису огромная благодарность) , читать тут http://www.1service.ru/blog/

    Reply
  43. dima_tuzov

    Сижу читаю «BDD in action — John Ferguson». Надеюсь поможет… А то когда статью писал, был дзен, а теперь каша в голове…

    Reply
  44. new_user

    (43) помогло?

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *