Я видел множество методологий разработки и десятки инструментов, но недавно открыл для себя новый способ Agile-сотрудничества, который меня очень вдохновил.
Какие?
Работа в быстром и гибком окружении может быть сложной задачей, однако одной из самых больших целей для Команды является сохранение высокого качества продукта. Первое, что мы можем предложить для поддержания высокого уровня, — это покрыть функциональность модульными тестами, но даже в этом случае это не может гарантировать, что все функции были реализованы так, как требовалось.
«Юнит-тесты гарантируют, что вы сделаете все правильно».
На этом этапе в игру вступает разработка через приемочное тестирование (ATTD).
«Приемочные испытания гарантируют, что вы создадите правильную вещь».
Есть несколько инструментов, которые могут помочь нам с ATTD: Fit, FitNesse и Cucumber, но в этот раз мы рассмотрим FitNesse.
Почему?
Если бы кто-нибудь попросил меня описать FitNesse, я бы, наверное, выбрал слова: универсальность, совместная работа и надежность. Я не случайно выбрал эти слова для описания методологии Scrum/Agile. Вся идея FitNesse вращается вокруг принципов Agile.
Как инженер-программист, я страдал от устаревшего метода передачи критериев приемлемости от клиента команде. Время решить, что мы должны улучшить.
Вики для всех. Подавляющее большинство документации, связанной с проектом, сосредоточено в кодовой базе разработчика. Не так уж сложно получить всю информацию о какой-то части функциональности из файлов функций Cucumber, но что делать членам команды, которые не могут получить доступ или изменить существующий исходный код — они вынуждены иметь дело с отдельным источником документации и в свою очередь это приводит Команду к рассинхронизации. Вот почему FitNesse поддерживает идею обмена информацией о вики/приемочных тестах через удобный веб-интерфейс.
Приемочные тесты для всех. Изменения могут внезапно появиться у всех, и важно как можно скорее получить информацию о возможном влиянии. «Похоже, FitNesse может помочь вам даже с этим» — где-то из-за угла выкрикивает дядя Боб. Каждый член команды (или даже клиент) может создавать или обновлять уже существующие критерии тестирования, чтобы проверить, как именно эти изменения влияют на текущую бизнес-логику.
Как?
Разобравшись с общей идеей FitNesee, давайте взглянем на обычный рабочий процесс.
Эта диаграмма представляет жизненный цикл пользовательской истории, и, глядя на нее, мы уже можем определить основную проблему — закрытая итерация. В принципе, изменения между начальной точкой и концом потока не приветствуются.
Почему это происходит? Это то, о чем я говорил в начале этой статьи — «перенос критериев приемлемости». Ключевое слово здесь — перенос. По сути, как только заказчик передает Команде критерии прохождения какой-либо пользовательской истории, в каждый момент эти критерии могут быть изменены заказчиком или неверно истолкованы, и все поймут это только в конце потока, на Знаке. Вне сцены.
Давайте посмотрим, чего мы можем добиться, если в нашем процессе у нас будет общий источник документации и приемочных тестов.
В обновленном процессе наше определение истории и жизненные циклы разработки не привязаны друг к другу, поэтому все изменения, которые могут появиться в процессе, могут быть обработаны намного проще, проблемы могут быть решены намного быстрее из-за общей точки интеграции.
Вывод
У вас есть общее представление о FitNesse и разработке на основе приемочных испытаний. Вы поняли, почему и когда вы должны использовать его для достижения высоких целей.
Не стесняйтесь продолжать обсуждение в разделе комментариев ниже.
Развлекайся!
