Правильный способ тестирования сценариев с огурцом (rails 2.3.8)

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

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

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

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

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

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

Кроме того, план можно обновлять и понижать, поэтому я также хочу протестировать его.

Заранее спасибо за помощь


ruby-on-rails cucumber bdd
person KensoDev    schedule 14.12.2010    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

Начните с написания истории огурца для желаемой функции. Например:

Feature: Create an account
  In order to use the application
  As a user
  I want to create an account

  Scenario: Create an account from home page
    Given I am on the home page
    When I follow "Sign up"
    And I fill in "Username" with "bob"
    And I fill in "Password" with "test123"
    And I press "Create"
    Then I should see "You have successfully signed up! You may now sign in."

Когда мы запускаем наши функции Cucumber с помощью команды cucumber features, первый шаг в сценарии завершится ошибкой, поскольку домашняя страница еще не существует. Чтобы создать его, мы можем рассматривать его как отдельную функцию. Поэтому мы могли бы написать еще одну функцию Cucumber, например:

  Scenario: Visitor visits the home page
    When I go to the home page
    Then I should see "Welcome to the Website of Awesomeness"

Запустив эту функцию, мы обнаружим, что в приложении Rails не определен корневой маршрут. Как только мы исправим эту проблему, нам понадобится контроллер, представление и текст в представлении. Пока что мы написали только тесты Cucumber.

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

  Scenario: Username must be filled out
    Given I am on the home page
    When I follow "Sign up"
    And I fill in "Password" with "test123"
    And I press "Create"
    Then I should see "Username cannot be blank."

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

Это было многословно, но это должно помочь вам начать практиковать BDD по-настоящему. Для получения дополнительной информации см. книгу RSpec (которая включает в себя множество сведений о методах использования Cucumber и RSpec извне): http://www.pragprog.com/titles/achbd/the-rspec-book

person Brian Rose    schedule 14.12.2010
comment
У меня есть все эти тесты, я сказал, что все основы, такие как проверка открытия счета, и все остальное уже реализованы. вопрос был конкретно по платежам и планам и ежемесячному выставлению счетов. - person KensoDev; 14.12.2010
comment
Начните с проверки логики домена для планов и платежей в вашем наборе модульных тестов, а затем работайте над созданием набора приемочных тестов, который будет работать на тестовых серверах вашего платежного провайдера. Одним из хороших ресурсов может быть просмотр примеров сценариев Cucumber, опубликованных Chargify в их документах, и почерпнуть оттуда идеи: docs.chargify.com/api-migrations#api-migrations-json-create - person Brian Rose; 14.12.2010