Как создавать надежные программы Ruby on Rails с помощью BDD

1656630852 kak sozdavat nadezhnye programmy ruby on rails s pomoshhyu bdd

Марк Анастасов

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

w-cGH0pyQD50cfQWGoB0EBzDfkdm91xuVbiZ

Почему мы падаем, сэр? Чтобы мы могли научиться подбирать себя.»
-Альфред (Майкл Кейн) в «Бэтмене: начало».

Я создал свою первую программу Rails десять лет тому назад. Я испытал все подходы, и если в чем-то я уверен, это в том, что я не могу работать без написания тестов. А написание тестов – это то, что больше всего помогло мне развить мои навыки программирования.

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

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

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

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

Понимание точки зрения «поведения».

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

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

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

Развитие, управляемое поведением (BDD) сосредотачивается на поведении – на том, что делает дело – на всех уровнях развития.

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

Коммуникационный шаблон «Дано/Когда/Тогда».

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

BDD упрощает язык, используемый для описания сценариев, в которых следует использовать программное обеспечение:

*Дано* какой-то контекст или состояние мира,

*Когда* что-то происходит,

*Затем* мы ожидаем какого-нибудь результата.

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

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

Обзор инструментов BDD для Rails

Ruby on Rails был первым веб-фреймворком, поставлявшимся с интегрированной системой тестирования. Это явилось трамплином для дальнейшего развития ремесла.

В то же время экспрессивность Ruby и повышение производительности при разработке веб-приложений с помощью Rails привлекли к сообществу многих опытных и высокопоставленных инженеров.

Когда вы создаете новую программу Rails с параметрами по умолчанию, она устанавливает сцену для тестирования test/unit, тестовая библиотека, поставляемая вместе с Ruby. Однако есть инструменты, облегчающие применение BDD. Я рекомендую использовать RSpec в качестве основной библиотеки тестирования и Cucumber для написания приемных тестов высокого уровня.

RSpec

RSpec – популярная библиотека тестирования BDD для Ruby. Вызываются тесты, написанные с помощью RSpec характеристики — это выполняемые примеры ожидаемого поведения части кода в заданном контексте. Это гораздо легче понять, прочитав следующий код:

describe ShoppingCart do  context "when first created" do    it "is empty" do      shopping_cart = ShoppingCart.new      expect(shopping_cart).to be_empty    end  endend

Хорошо написанные спецификации легко читать и, следовательно, понять. Попытайтесь прочитать приведенный выше фрагмент кода вслух. Мы есть описывая корзина для покупок, говоря, что учитывая пустой контекст, когда мы создаем новую корзину для покупок, мы expect(shopping_cart).to be_empty.

Запуск этой спецификации дает результат, напоминающий спецификацию:

ShoppingCart  when first created    is empty

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

огурец

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

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

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

Feature: Reading articles
Scenario: Commenting on an article  Given I am logged in  And I am reading an article with "2" comments  When I reply to the last comment  Then the article should have "3" comments  And I should be subscribed to follow-up comments

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

Цикл BDD в Rails

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

Цикл BDD в Rails состоит из следующих шагов:

  1. Начните с нового сценария Cucumber. Прежде чем писать, обязательно проанализируйте и поймите проблему. На этом этапе вам нужно знать, как пользовательский интерфейс позволяет пользователю выполнять работу. Не беспокойтесь о реализации шагов сценария.
  2. Запустите сценарий и посмотрите, как он провалится. Это укажет вам, какие шаги не выполняются или ожидают выполнения. Сначала большинство ваших шагов будет ожидать (не определено).
  3. Напишите определение первой неудачной или ожидаемой спецификации. Запустите сценарий и посмотрите, как он провалится.
  4. Испытайте внедрение представления Rails используя цикл рефактора красно-зеленого цвета из RSpec. Вы узнаете об переменных экземплярах, контроллерах и действиях контролеров, которые понадобятся представлению для выполнения своей работы. Это также единственный этап, который на практике доказан как необязательный. Альтернативный подход состоит в том, чтобы просто подготовить представления и контроллеры перед переходом к следующему шагу.
  5. Проведите тест-драйв контроллера используя цикл рефактора красно-зеленого цвета из RSpec. Убедитесь, что переменные экземпляра предназначены и правильно соответствующие действия. Контроллеры обычно руководствуются издевательским подходом. Позаботившись о контроллере, вы будете знать, что должны делать модели или объекты домена.
  6. Тест-драйв объектов домена используя тот же красно-зеленый цикл рефактора из RSpec. Убедитесь, что они предоставляют методы, необходимые для контроллера и представления. Если вы работаете над новой функцией, для которой еще нет модели, вам следует создать модель и соответствующие миграции базы данных. На этом этапе вы будете точно знать, что вам нужно сделать.
  7. После того, как вы реализуете все необходимые вам объекты и методы, и соответствующие спецификации пройдены, запустите сценарий Cucumber, с которого вы начали, чтобы убедиться, что шаг выполнен.
8WeEWJUk4SLlPc0tC5VrxooSOTwqSZaRHvr0
Цикл BDD в веб-разработке Ruby on Rails

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

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

Эта публикация адаптирована с Учебник по тестированию Rails, бесплатная электронная книга, изданная Semaphore. Если вы зашли так далеко и хотите увидеть практические примеры написания кода, управляемого поведением, загрузите книгу и дайте мне знать, что вы о ней думаете. Спасибо!

Добавить комментарий

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