Язык геркин для 1с + видео обзор

Содержание
  1. Gherkin¶
  2. Функции (Feature)¶
  3. Сценарий (Scenario)¶
  4. Структура сценария (Scenario Outline)¶
  5. Предыстории (Background)¶
  6. Данные (Givens)¶
  7. Действия (Whens)¶
  8. Результаты (Thens)¶
  9. Предлоги (And, But)¶
  10. Таблицы¶
  11. Gherkin: говорим с автоматизаторами на одном языке
  12. На каких языках «говорят» автоматизаторы?
  13. Кто использует решение по автоматизации?
  14. Чем интересен BDD-подход?
  15. Описываем тестовые сценарии на языке Gherkin
  16. Обычно юзер-стори записывается в следующем формате:
  17. Пример структуры спецификации
  18. Использование языка Gherkin удобно по ряду причин:
  19. Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории
  20. Gherkin и представители бизнеса / аналитики
  21. Gherkin и разработчики
  22. Gherkin и someone else?
  23. Подведем итог
  24. BDD: Адаптация языка Gherkin для русскоязычных проектов в Asp.Net
  25. Пролог
  26. Как это выглядит сейчас
  27. Чем этот подход плох
  28. Как это можно сделать по-другому
  29. Адаптируем BDD для разработки на 1С совместно с cucumber и 1Script
  30. BDD, DDD, TDD, PDD, SDD и остальные DD
  31. Окружение разработчика BDD для eDSL
  32. Тестирование конечной задачи, это не тестирование алгоритма функции
  33. Обычный типовой процесс для разработчика
  34. Инвентаризация функционала и технический долг
  35. Видео

Gherkin¶

Обработчик разбивает файл с тестами на функции, сценарии и входящие в них шаги. Давайте разберем этот пример:

Функции (Feature)¶

Каждая функция описывается в отдельном файле с расширением .feature. Первая строчка должна начинаться с ключевого слова “Функция:”, за которой могут идти три строчки с описанием, размеченные отступами. Каждая функция обычно состоит из списка сценариев.

Каждый сценарий состоит из списка шагов, каждый из которых должен начинаться с одного из ключевых слов:

Шаги “Но” и “И” существуют исключительно для удобства чтения и по своим функциям повторяют ключевое слово, с которого начиналась предыдущая строчка.

Вдобавок к сценариям, описание функционала может также содержать структуры сценариев и предыстории.

Сценарий (Scenario)¶

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

Каждый из следующих сценариев содержит три шага:

Структура сценария (Scenario Outline)¶

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

Структуры сценариев позволяют нам более кратко описывать подобные наборы сценариев с помощью шаблонов:

Шаги указанные в структуре сценария не выполняются напрямую, но используются для подстановки в них значений из таблицы примеров. Каждая строчка таблицы будет обрабатываться как отдельный сценарий с указанными значениями вместо заглушек “было”, “удалено” и “стало”.

Предыстории (Background)¶

Функции состоят из шагов, также известных как Данные, Действия и Результаты.

Данные (Givens)¶

Назначение шагов Дано состоит в приведение системы в известное состояние перед тем как пользователь (или внешняя система) начнет взаимодействие с системой (в шагах Когда). Также можно рассматривать их как предусловия.

Пример: создавать объекты сущностей или настраивать БД

Пример: вход пользователя в систему (исключение к правилу “никаких взаимодействий в шаге Дано”)

Действия (Whens)¶

Назначение шагов Когда состоит в описании ключевого действия, совершаемого пользователем.

Пример: взаимодействие со страницей

Результаты (Thens)¶

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

Предлоги (And, But)¶

Если у вас есть несколько шагов Дано, Когда, или То то вы можете писать так:

. или можете использовать шаги И и Но, превращая свой сценарий в нечто более читаемое:

Таблицы¶

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

Источник

Gherkin: говорим с автоматизаторами на одном языке

В данной статье Сергей Сенюк, менеджер команды автоматизаторов a1qa, знакомит нас с языком Gherkin, позволяющим описывать сценарии для тестирования и создавать автотесты, не заглядывая в программный код.

На каких языках «говорят» автоматизаторы?

Для создания фреймворка по автоматизации и базирующихся на нем автотестов разработчики используют различные языки: C#, JavaScript, Ruby и т.д.

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

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

Кто использует решение по автоматизации?

После того, как решение по автоматизации написано и передано клиенту, использовать его могут следующие команды:

Очень четко эту проблему сформулировал один из наших потенциальных клиентов после того, как мы продемонстрировали ему наш фреймворк и подходы к автоматизации. Он высказал вполне закономерные опасения, что его внутренняя QA-команда, не имеющая опыта в написании кода, просто не сможет поддерживать написанные автоматизаторами тесты, не говоря уже о самостоятельном создании новых тестов по мере развития продукта. Решением в данной ситуации станет BDD (Behavior-Driven Development) подход.

Заказать консультацию по автоматизации тестирования ПО можно здесь.

Чем интересен BDD-подход?

Когда конечными пользователями решения выступают тестировщики, не обладающие навыками программирования, мы предлагаем создание решения на основе BDD к автоматизации тестирования.

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

BDD-подход интересен тем, что тесты к нему пишутся с помощью сценариев.

Сценарий – описание поведения определенной функциональности системы, составленное на естественном языке по определенному шаблону. Важно, что для подготовки сценариев используются общеупотребительные языки (ubiquitous language). Это позволяет автоматизаторам и тестировщикам заказчика легко составлять сценарии вместе.

Общеупотребительный язык – определенные лингвистические конструкции, интерпретируемые программным кодом автотестов. Как следствие, отпадает необходимость трудозатрат на преломление, изменение или же конкретизацию документации под разработку или QA. Сценарии изначально едины и неизменны для всех вовлеченных в проект команд.

Описываем тестовые сценарии на языке Gherkin

Язык, на котором составляются подобные тестовые сценарии, – Gherkin. Он выполняет сразу две задачи:

Поведение системы описывается на естественном языке, но в так называем «Given/When/Then» формате. Каждая непустая строка в Gherkin начинается с ключевых слов, за которыми следует описание.

В соответствии с BDD-подходом, спецификации должны иметь следующую структуру:

Название. Спецификация должна иметь четкое, явное название, отражающее суть тестируемой функциональности.

Повествование. Краткий вводный раздел, который определяет:

Обычно юзер-стори записывается в следующем формате:

Как (As a) [X]
Я хочу (I want) [Y]
Чтобы (so that) [Z]

где Y – это некая функциональность («фича»), Z – это выгода, которую мы от нее получаем, или ценность, а X – это человек или группа людей, которая получит ценность от данной функциональности.

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

Другое дело – блок сценариев в Gherkin, где каждая строка представляет собой шаг, причем каждый шаг соответствует одному из методов программного кода.

Сценарий начинается с задания начального состояния — предусловия. Оно может состоять из одного пункта или сразу нескольких и в Gherkin следует за ключевым словом [Given].

После начального состояния описываются действия, совершающиеся в ходе сценария — в Gherkin они следуют за ключевым словом [When].

И наконец, описывается ожидаемый результат в одном или нескольких пунктах [Then].

Если шагов в блоках Given, When или Then несколько, то каждый из них записывается с новой строки и следует за ключевым словом And.

Пример структуры спецификации

Функциональность: Вход в приложение

Как пользователь

Я хочу войти в свой аккаунт

Чтобы совершить платеж онлайн

В Gherkin данный сценарий будет описываться следующим образом:

Given User is on Login Page

When User enters following credentials and submit

Then ‘Welcome to our site’ message should be displayed

Разработчики BDD-фреймворков поддерживают мультиязычность. Фреймворк Cucumber, например, включает в себя более 60 языков, и это число постоянно растет.

Спецификация на русском языке будет выглядеть следующим образом:

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

Когда пользователь вводит следующие данные

Тогда должно появиться приветственное сообщение

Использование языка Gherkin удобно по ряду причин:

Из следующей статьи вы узнаете, как построить эффективную стратегию взаимодействия между ручными тестировщиками и автоматизаторами на проектах, где внедрены подходы BDD.

Источник

Кто вы, пишущие на Gherkin? Или корнишон в поисках целевой аудитории

Язык геркин для 1с

Не так давно среди моих знакомых возник вопрос: “Зачем Gherkin?”. Причем вопрос был поставлен не как вброс на лопате, а чтобы понять его применимость.

Старт обсуждению дал kuntashov в G+ заметкой со следующим содержанием (сюда я привожу сухой остаток, совсем немного подкорректированный мной):

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

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

Может все же использовать языки, которые больше повернуты лицом к программистам?

Если есть желание совместно разобраться в полезности Gherkin и для кого он предназначен, добро пожаловать под кат.
Подчеркну, что Gherkin = BDD, но BDD ≠ Gherkin.

Gherkin и представители бизнеса / аналитики

Изначально Gherkin позиционировался как инструмент для аналитиков и представителей бизнеса. Немного поясню, что под представителями бизнеса я понимаю бизнес-экспертов, владельцев продуктов, аналитиков, экспертов предметной области и т.п.

Почему же он не едет?

Не смотря на максимальную приближенность Gherkin к человеческому языку, это все же язык программирования. Т.е. мы просим бизнес немного попрограммировать… Как большинство людей поступает, когда их просят делать что-то, в чем они не особо разбираются и, по большому счету, не должны разбираться? Прокрастинируют или бунтуют.

Gherkin и разработчики

Итак, определились. Представители бизнеса описывать формальные сценарии, как правило, не могут и не хотят. Хорошо, перекинем это на плечи разработчиков.

Почему и тут не едет?

Дело в том, что у подавляющего большинства разработчиков мозг устроен так, что у них когнитивное сопротивление против написания тестов до кода. Я помню свои ощущения, когда начал пробовать TDD. Абсолютно ломается привычный способ мышления, было такое ощущение, что у меня меняются местами левая и правая половинки мозга… КАК? КАК я могу тестировать то, что еще не написано. Только после перестроения мышления такой подход начинает ощущаться как естественный и начинает приносить пользу.

Более того, далеко не все разработчики умеют проектировать сценарии тестирования. Проектирование сценария тестирования — это особый процесс, который так же не является естественным для разработчиков. Разработчики — творцы, которым не до вопросов валидации и верификации.

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

Gherkin и someone else?

Хорошо, представители бизнеса не могут / не хотят, разработчики не могут / не хотят. Так для кого был придуман этот инструмент? Кому он может быть полезен?

Может проблема кроется в неправильном позиционировании и неправильном выборе целевой аудитории?

А что если предположить, что целевая аудитория Gherkin — это тестировщики? Причем не просто тестировщики, а гибкие тестировщики (agile testers). Навык создания сценариев тестирования у них в крови. Склад ума позволяет вычленять самые важные и нужные сценарии для тестирования и легко их описывать. Еще, это люди, которым впоследствии предстоит тестировать будущую систему. А значит, они заинтересованы в том, чтобы система, которая к ним попадет — имела четко заданные спецификации и сценарии поведения.

Да, это переворачивает привычную логику. Да, тестер начинает свою работу до того, как что-то будет разработано. Но ведь по сути TDD и BDD это как раз об этом…

Тут возникает вопрос: “Бизнес-аналитика меняем на гибкого тестировщика вооруженного Gherkin что ли?”.
Нет, не меняем. Мы дополняем команду формулирования требований тестировщиком. Для пояснения хочу сослаться на матрицу тестирования:
Язык геркин для 1с
На мой взгляд, Gherkin, явный представитель бизнес-ориентированных тестов, которые поддерживают разработку. Иными словами — это второй квадрант (Q2). Тесты этого квадранта в первую очередь направлены на сбор требований. Как бы мог выглядеть процесс сбора требований, когда у нас есть тестировщик с Gherkin?

В современной разработке новые фичи начинают свою жизнь в виде пользовательских историй, написанных командой бизнеса. Написание историй не подразумевает проработку деталей. Истории предназначены только для того, чтобы служить отправной точкой диалога между командами бизнеса и разработки. Здесь важную роль играют тестировщики, которые помогают выбрать примеры и контекст для каждой пользовательской истории. Именно в этот момент рождаются сценарии Gherkin и появляется общее информационное пространство для всех участников процесса. Понимая проблематику бизнеса, технические специалисты смогут предложить более практичные в реализации альтернативы. Полученные в результате обсуждения сценарии использования (use-cases) одобряются бизнесом. В дальнейшем эти сценарии являются руководством для разработчиков в процессе написания кода и помогают узнать, когда код начинает удовлетворять требованиям бизнеса.

Подведем итог

Для команды бизнеса Gherkin может быть полезен только если в команде есть специалист, разбирающийся в технологиях и с задатками программиста.

Разработчикам Gherkin скорее не помогает, а заставляет выполнять какие-то дополнительные, возможно, ненужные действия. Для разработчика автоматизацию тестирования проще выполнять в первом квадранте (Q1) матрицы тестирования, на уровне модульных тестов, просто выглядеть они могут в стиле BDD (codeception, mocha.js и т.п.).

Тестировщики, на мой взгляд, оптимальная целевая аудитория для Gherkin. Программируют далеко не все тестировщики, но они смогут довольно легко овладеть Gherkin’ом. На раннем этапе выполняется часть работы по тестированию и остается время для других видов тестирования, например, исследовательского.

Так же хочу отметить, что, на мой взгляд, тесты из квадрантов 1 и 2 (Q1 и Q2) ни в коем случае не должны противопоставляться, они прекрасное дополнение друг к другу!
Тесты первого квадранта дают такой замечательный артефакт, как качественный дизайн программного кода.
Тесты второго квадранта дают уверенность в том, что бизнес получит то, что он ожидает, а не то, что получилось.

Источник

BDD: Адаптация языка Gherkin для русскоязычных проектов в Asp.Net

Я напишу, как можно адаптировать популярный язык написания тестов Gherkin для русскоязычных проектов без использования сторонних библиотек, а также поделюсь своим опытом использования этого подхода.
Статья — не перевод, она от начала и до конца является описанием моей точки зрения. Тем не менее, прийти к ней мне помог блог Стива Сандерсона (Steve Sanderson). Рекомендую прочитать его статьи, помеченные тегом «Testing».

Пролог

TDD-подход в разработке ПО заслуженно завоевал свое место под солнцем. В течение жизни он постепенно переосмыслялся, переходя из разряда методов для поиска багов в разряд методов для описания архитектуры приложения. Следующим шагом, органично дополняющим эволюционировавший TDD является BDD — Behavior Driven Development.

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

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

В последнее время BDD применяется чаще в вебе, по большей части из-за того, что его модель сценариев органично вписывается в принцип «запрос-ответ».

Как это выглядит сейчас

Scenario: Show logged in user name
Given I am logged in as a user called «Vlad»
When I visit the homepage
Then the page header displays the caption «Здравствуйте, Vlad!»

Для каждого действия он также пишет соответствующие функции:

Given /I am logged in as a user called «(.*)»/ do |name|
create_user(name)
sign_in_as(name)
end

Then /the page header displays the caption «(.*)»/ do |caption|
page_header.should_contain(caption)
end

Таким образом Cucumber или SpecFlow сможет интерпретировать каждый шаг, вычленить с помощью регулярных выражений параметры и запустить соответствующие TestFixtures. В результате мы получаем test-suit, полностью написанный на человеческом языке и понятный каждому участнику проекта.

Чем этот подход плох

Ну во-первых тем, что для его использования нужно устанавливать SpecFlow. Тем более, как я опишу чуть ниже, реальная потребность в таком инструменте отсутсвтует, все можно сделать средствами Visual Studio.

Во-вторых, у SpecFlow есть проблемы с русским языком и чтобы корректно настроить его под кириллицу нужно приложить немало усилий. Тут можно возразить, что, мол, все мы айтишники и понимаем английский и что русский в коде нам ни к чему. Это не так. Русский язык позволяет резко увеличить читаемость сценариев и отказаться от мучительного процесса перевода языка предметной области на английский.

Как это можно сделать по-другому

Очень просто. С некоторых пор Visual Studio позволяет именовать методы класса с использованием русского языка, по сути это все что нам нужно. Пример выше можно написать так:

[TestMethod]
public void Отображение_имени_залогиненного_пользователя()
<
Если_я_залогинен_как(«Vlad»);
Когда_я_перехожу_на_главную_страницу();
Я_вижу_на_странице_текст(«Здравствуйте, Vlad!»);
>

Шаблон Given/When/Then трансформируется здесь в Если/Когда/_. По инерции можно было бы переименовать этот шаблон в Если/Когда/Тогда, но написание «Когда я перехожу на главную, я вижу на странице текст „привет“» смотрится намного более органично чем «Когда я перехожу на главную, тогда я вижу на странице текст. ». Таким образом, последнее слово «Тогда» я рекомендую просто опускать для улучшения читаемости.

Работает все это крайне просто — каждый тест-класс нужно отнаследовать от базового, в котором определены все необходимые Given/When/Then шаги.

При написании интеграционных тестов я объединяю в тест-классе связанные фичи-регионы, которые в содержат функции-сценарии. Вот как выгладит AccountIntegrationTest:

Язык геркин для 1с

Если вы уже писали интеграционные тесты (к примеру с использованием WatiN) то вы оцените насколько упростится этот процесс. Вот как раньше выглядел мой сценарий отправки сообщения через форму обратной связи:

[TestMethod]
public void Отправка_сообщения_с_заголовком_и_текстом_без_имейла()
<
string caption = U.GetRandomString();
string text = U.GetRandomString();

using (IE ie = new IE())
<
U.Logout(ie);
ie.GoToContacts();
ie.TextField(«Caption»).Value = caption;
ie.TextField(«Text»).Value = text;
ClickOnSendMessage(ie);
ie.Text.ShouldContain(«Сообщение успешно отправлено»);
Div div = U.GetLastUnreadMailMessageText(ie);
div.Text.ShouldContain(text);
>
>

А вот как он выглядит сейчас:

[TestMethod]
public void Отправка_сообщения_с_заголовком_и_текстом_без_имейла()
<
Если_я_не_залогинен();
Если_я_нахожусь_на_странице_обратной_связи();
Когда_я_печатаю_текст_в_поле(«Заголовок», «Заголовок для обратной связи»);
Когда_я_печатаю_текст_в_поле(«Текст», «Сообщение для обратной связи»);
Когда_я_кликаю_по_кнопке_с_надписью(«Отправить»);
Я_вижу_сообщение(«Сообщение успешно отправлено»);
Админу_приходит_письмо();
В_этом_письме_содержится_текст(«Сообщение для обратной связи»);
>

В некоторых случаях для выполнения шага ему нужен контекст — результат выполнения предыдущего шага («В_этом_письме_содержится_текст» использует результат работы «Админу_приходит_письмо»). Его также можно спрятать в базовом классе в виде protected object _lastActionResult; и обращаться к нему при необходимости.

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

Источник

Адаптируем BDD для разработки на 1С совместно с cucumber и 1Script

Кто платит за тестирование решений? Особенно в случаях если заказчик (внутренний или внешний) просит запустить систему учета, и не указывает насколько плохая система ему нужна? Этот вопрос вызывает достаточно большую волну “священных войн” при любой разработке, любых решений. Написаны они на 1С или не на 1С — это извечная “драка”: никто не любит тестировать, все любят “кодить” новые и интересные задачи.

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

BDD, DDD, TDD, PDD, SDD и остальные DD

Размышляя над проблемой тестирования, а точнее над проблемой качества решений, умные и не очень люди, в основном ломают копья.над следующим противоречием

Язык геркин для 1с

“надо тестировать, но надо разрабатывать, а не тестировать”.

Также к этому добавляется другое противоречие

“надо предусмотреть все возможные действия будущего пользователя, но нельзя предусмотреть ВСЕ действия будущего пользователя”

Язык геркин для 1с

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

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

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

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

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

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

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

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

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

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

Вдруг кто не в курсе что это за аббревиатуры:

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

Язык геркин для 1с

Окружение разработчика BDD для eDSL

Но вернемся к тестированию. Итак, на входе у нас следующие данные:

Мы хотим попробовать создать возможность разрабатывать через поведение на платформе 1С

Для работы нам понадобится:

а также концепт отражающий подход к тестированию 1С решение через поведение:

в качестве дополнительно подмодуля мы будем использовать

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

ruby нам понадобится чтобы установить «огурец»
python — используется для работы с hook’ами git (дело в том, что для получения исходных файлов мы используем перехват помещения бинарных 1С файлов в репозиторий: ведь в репозитории исходных кодов все же должен быть исходный код).

Для тех, кто в данный момент испытывает боль от резкого перехода с теории к практическим работам, предлагаю смириться и продолжить чтение:

Первое что вы должны понять, тесты — это тоже код. А для кода мы просто обязаны сделать хранилище кода. Поэтому:

теперь осталось только разобраться где хранить тесты на сервере git

всё остальное типовые команды при работе с исходными кодами:

Тестирование конечной задачи, это не тестирование алгоритма функции

Перейдем непосредственно к задаче. Тут опять придется несколько отвлечься и сказать, что при запуске разработки автоматизированного тестирования 1С, основная проблема это как раз непонимание “как тестировать” конечный бизнес-функционал. Возможно здесь также играет “злую штуку” название известного проекта xUnit — которое отсылает нас к en.wikipedia.org/wiki/XUnit, где мы читаем много умных слов, но они слишком далеки от конечного тестирования бизнес-задачи.

И вот тут у начинающего разработчика, которому поставлена задача на автоматизированное тестирование, начинается “ломка стереотипов”, дело в том что Конфигуратор 1С позволяет сразу реализовывать полученное ожидаемое поведение, без необходимости его обдумывать и задавать вопрос “зачем” и “кому” необходим функционал. Изначально считается что все заказчики-бизнесмены и специалисты по eDSL языку максимально находятся “в контексте”. Для одного поведения это скорее всего так, а вот для комплекта ожидаемых поведений и сложных сценариев ни один мозг не сможет удержать в контексте весь сценарий задачи. Как раз за этим мы и начинаем относится к ожидаемому поведению как к коду.

Обычный типовой процесс для разработчика

Задача от заказчика (в системе учета задач) звучит исходно так

“Необходимо что деньги учитывались как аванс, если клиент оплатил больше чем мы ему отгрузили”

Теперь посмотрим как это выглядит в реальности и прикинем что нам нужно для BDD в 1С:

Дальше идет достаточно важный и очень обязательный шаг при «разработке через поведение» — мы пишем ожидаемый сценарий поведения (или аналитики за нас, или грамотный заказчик). Фактически Gherkin, а мы будем использовать именно его, спасёт нас здесь, тем, что мы имеем DSL язык для описания группы будущих тестовых сценариев. Наверное вы удивились что я сказал про будущие тесты? Но вы должны смирится — после использования BusinessReadableDSL для описания сценария происходит понимание что же действительно нужно протестировать, и что же действительно нужно реализовывать (ищете статью Мартина Фаулера на эту тему).

Итак, у нас есть feature файл, который мы напишем на основе исходной постановке задачи, следующего содержания:

Запускаем vanessa-behavior.os с параметром “GenerateEpf” и получаем на выходе готовый файл обработки для тестирования:

и получаем то ради чего всё это затевалось — обработку тестирования на основе поведения, которую мы затем и наполняем при помощи кода на встроенном языке 1С

Язык геркин для 1с

Как видно — произошло следующее:

Для каждой строки feature файла была создана процедура.

Были определены параметры для вызова этих процедур (число, строка, дата), а также были определены, так называемые сниппеты, например:

Давайте посмотрим, что с этим добром можно делать.
Первое, что бросается в глаза, что имя параметра Парам01Строка не очень наглядный. Что же, берём и меняем ему имя, скажем, на НазваниеКонфигурации. Да и имя процедуры заменим на СуществуетКонфигурация.
Получится:

Но тут может получиться ситуация, что если попытаться ещё раз сгенерировать обработку 1С по тому же feature файлу, то программа не сможет найти процедуру со старым именем и всё перестанет работать. Но тут нам на помощь приходит сниппет

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

Второе, что можно заметить, это то что в feature файле были две похожие строки:

Но для них был создан только один метод:

Что не удивительно, ведь для обеих строк сниппет будет одинаковый. Таким образом может показаться, что тут назревает повторное использование кода. Иииииииии… Да! Это оно и есть! Если где-нибудь в этом feature файле (или в любом другом этого же проекта) мы напишем что-то вроде:

то окажется, что этот код тестирования уже реализован в методе СуществуетДоговорСДатойДоговора.

Мало того, может оказаться, что этот метод реализовал вообще кто-то другой до нас. И мы просто его переиспользуем. И это произойдёт само собой. Это ли не мечта любого программиста! Заказчик пишет что он хочет (а это и есть наш feature файл) — а половина кода уже реализована, протестирована (т.е. покрыта тестом) и будет подхвачена на лету!
Welcome to the BDD, my friend!

Язык геркин для 1с

Подведём мини итог.

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

Инвентаризация функционала и технический долг

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

Происходит это по двум причинам:

Отдельно стоит сказать, как это все начиналось и как развивалось, По моей версии это было так (хотя старшие товарищи могут меня поправить).

Начиналась проверка концепции xDD (а точнее с TDD), еще в далеком 2004 году и на платформе 1С 7.7. Принято считать, что лидерами здесь являются Московская школа по тестированию — в том числе в рамках проекта www.1cpp.ru и Ижевская школа по тестированию www.kint.ru

С выходом версии 1C 8.* никто и не собирался отказываться от уже наработанных процессов, однако закрытость платформы привела к невозможности прямым способом портировать наработки. Процесс немного остановился.

В итоге появились первые draft’ы infostart.ru/public/15492 очень даже работоспособные, и уже при объединение нескольких наработок и родился проект github.com/xDrivenDevelopment/xUnitFor1C, для развивающих качество своих решений разработчиков на платформе 1С. Лидером в данном продукте является Артур Аюханов с командой единомышленников.

Но нельзя не вспоминать об Ижевской школе тестирования 1С решений. На данный момент основным фронтменом здесь является Ижевское тестирование систем — команда здесь построила схему монетизации тестирования и развивает уже свою линейку коммерческих продуктов.

Проект vanessa-behavior является продолжением развития концепции xDD, но уже с другим подходом — теперь не от тестов, а от требования к поведению.

Q: Зачем здесь Gherkin
A: DSL язык Gherkin для описания требований — это прямая отсылка вас к проблеме управления требованиями и как она решается автоматизировано.

Источник

Видео

"Hello, 1C!": пишем первую программу на языке программирования 1С

"Hello, 1C!": пишем первую программу на языке программирования 1С

BDD в 1С. Написание простой фичи на языке Gherkin.

BDD в 1С. Написание простой фичи на языке Gherkin.

Язык Gherkin. Как описать автоматический тест понятным человеку языком

Язык Gherkin. Как описать автоматический тест понятным человеку языком

Запросы в 1С за 3 часа

Запросы в 1С за 3 часа

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

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

Сценарии поведения из воздуха

Сценарии поведения из воздуха

Язык къхонг - Георгий Старостин

Язык къхонг - Георгий Старостин

Константин Гейнрих. О формах 1С замолвите слово.

Константин Гейнрих. О формах 1С замолвите слово.

Как разработать собственный язык программирования на примере LENS

Как разработать собственный язык программирования на примере LENS

Уроки по СКД. Расширение языка запросов для СКД. Секция Где

Уроки по СКД. Расширение языка запросов для СКД. Секция Где
Поделиться или сохранить к себе:
Добавить комментарий

Нажимая на кнопку "Отправить комментарий", я даю согласие на обработку персональных данных, принимаю Политику конфиденциальности и условия Пользовательского соглашения.