Эта статья является продолжением первой части и раскрывает технические подробности работы с «исполняемой спецификацией» с помощью SpecFlow.
Для начала работы вам понадобится плагин к Visual Studio (скачивается с официального сайта) и пакет SpecFlow (устанавливается из nuget).
Итак, наш Product Owner попросил команду разработать калькулятор…
Читать полностью »
SpecFlow позволяет использовать встроенные таблицы для Data Driven сценариев. В своей практике я столкнулся с двумя проблемами при таком подходе:
Покопавшись в Gesigner Generated коде я смог решить обе проблемы.
Автоматизация тестирования – место встречи двух дисциплин: разработки и тестирования. Наверное поэтому, я отношу эту практику к сложным, но интересным.
Путем проб и ошибок мы пришли к следующему технологическому стеку:
Для запуска тестов по расписанию мы используем TFS 2012 и TeamCity.
В статье я опишу, как мы к этому пришли, типовые ошибки и пути их решения.
Читать полностью »
Недавно я задался вопросом поиска инструментария для разработки мобильных приложений на html/css. Из требований были: доступность, легковесность, простота настройки. Выбор пал на встроенный Node менеджер NPM. NPM содержит
инструментарий для базовых тасков типа install и запуска пользовательских скриптов. Также NPM не такой громоздкий, как Grunt и не требует адаптации модулей под себя, т.к. запускает модули с командной строки.
Недавно я задался вопросом поиска инструментария для разработки мобильных приложений на html/css. Из требований были: доступность, легковесность, простота настройки. Выбор пал на встроенный Node менеджер NPM. NPM содержит
инструментарий для базовых тасков типа install и запуска пользовательских скриптов. Также NPM не такой громоздкий, как Grunt и не требует адаптации модулей под себя, т.к. запускает модули с командной строки.
Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:
В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.
В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!
Читать полностью »
Поскольку идея данного поста родилась у меня независимо от эпопеи с хлебопекарней, хочу вставить и свои пять копеек.
Итак, суть проблемы — поставить программный код в соответствие с бизнес-требованиями. Существуют замечательные методологии и техники, например, Behavior Driven Development (BDD), которые позволяют в декларативном стиле описать требуемое поведение системы (тесты).
Возникает вопрос — зачем описывать как должен работать код, если можно и сам код написать в этих терминах. Почему user story не может быть самой программой.
не код должен генерироваться из модели — модель должна быть кодом
Чтобы не томить читателей сразу перейду от слов к делу. Представим себе язык для программирования вот такого робота:
Warning! Данный пример служит только для иллюстрации идеи и не предназначен для приготовления пищи в реальной жизни. Автор не несет ответственности за вред здоровью нанесенный в результате употребления пищи, приготовленной с помощью данного примера.
Данная статья является продолжением первой части «Введение в Jasmine». Здесь рассматриваются дополнительные возможности тестового фреймворка Jasmine, а именно:
Программирование на стороне клиента давно стало нормой, а объем JavaScript кода и его сложность постоянно растут. Часто тестирование применяется только на серверной стороне, но при этом не стоит забывать о тестировании клиентского кода. Для тестирования JavaScript как на стороне клиента, так и для Node.js можно с успехом применять Jasmine.
Jasmine это BDD фреймворк (Behavior-Driven Development — Разработка на Основе Поведений) для тестирования JavaScript кода, позаимствовавший многие черты из RSpec.
На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.
Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.
Читать полностью »
