NET для Ruby: обучение написанию тестов, часть II

 class Calculator
  def push(n)
    @args ||= []
    @args << n
  end
end

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

Снаружи

Будут времена, когда мои объекты потребуют более тщательных и детальных испытаний. В этот момент я захожу в RSpec и пишу там свои тесты. Другими словами, с помощью «историй о функциях», созданных с помощью Cucumber, я тестирую поведение «приложения», при этом следя за тем, чтобы у объекта был самый минимальный объектный API для включения этой функции. С другой стороны, с помощью спецификаций, созданных с использованием RSpec, я тестирую поведение своих «объектов», при этом следя за видами сотрудничества и зависимостями, которые нужны моим объектам для выполнения своей работы.

Этот подход также известен как разработка «извне»: я начинаю снаружи приложения, где я очень близок к людям, которые будут использовать мое приложение. Затем я перемещаюсь во внутренние объекты, которые включают функции, которые мы запрашиваем извне. Для меня это отход от подхода «сначала подумай об объектах», которому я следовал раньше. Пользователи моих приложений не заботятся об объектах!

Создание функции без запуска приложения

В прошлом я создал несколько приложений, таких как это:

1. Создать вид
2. Запустите приложение
3. Просматривайте многочисленные меню и экраны, пока я не доберусь до представления, созданного на шаге 1
4. Зайдите в код и отбросьте точку останова
5. Нажмите на кнопку в приложении
6. Подождите, пока эта точка останова не будет достигнута
7. Зайдите в отладчик и посмотрите вокруг
8. Повторите шаги несколько раз, и в конце концов моя функция выполнена

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

Построение и тестирование API REST

Совсем недавно я закончил работу по созданию REST API в одном из моих приложений на Rails. Этот API обслуживал JSON, используемый мобильными приложениями. Я описал API с историями функций Cucumber, которые работали как документация для моего API и имели приятный «побочный эффект» — автоматические тесты для обеспечения работы API.

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

Вот небольшой пример функции, поддерживаемой этим API:

 Feature: User authentication

  In order to only allow authenticated users to use our applications
    As an API client
    I want to be able to authenticate a user based on his credentials

  Scenario: Authentication Failed

  Given invalid credentials
    When I send a request for user authentication
    Then the response should be "200"
     And I should receive message indicating authorization failure

  Scenario: Authorization Succeeded

  Given valid credentials
    When I send a request for user authentication
    Then the response should be "200"
     And I should receive message indicating authorization success

И вот пример того, как эти шаги реализованы:

 Given /^invalid credentials$/ do
  @login = "INVALID_LOGIN"
  @password = "INVALID_PASSWORD"
end

Given /^valid credentials$/ do
  @user = Factory(:athlete_user)
  @login = @user.email
  @password = @user.password
end

When /^I send a request for user authentication$/ do
  post "api/v3/user_authentication.json?login=#{@login}&password=#{@password}"
end

Then /^I should receive message indicating authorization success$/ do

  success = {:user_authentication =>
               {:status => "success",
                :errorcode => nil,
                :errormessage => nil,
                :login => @login,
                :profile => 'athlete'}}

  last_response.body.should == success.to_json
end

Then /^I should receive message indicating authorization failure$/ do

  error = {:user_authentication =>
               {:status => "failed",
                :errorcode => "UNKNOWN_LOGIN",
                :errormessage => "Invalid credentials.",
                :login => nil,
                :profile => nil}}

  last_response.body.should == error.to_json
end

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

Это то, что делают все разработчики Ruby?

Нет !! Это не то, что делают все разработчики Ruby. Некоторым разработчикам совсем не нравятся RSpec и / или Cucumber, и вместо этого они используют другие тестовые среды. Люди используют то, что имеет для них смысл. То, что я описываю здесь, — это то, что я считаю лучшими процессами и инструментами для работы, которую я делаю, в проектах, над которыми я сейчас работаю. Это определенно не универсальное решение, и это не значит, что я не постоянно ищу разные вещи, которые люди делают или используют.

Я пишу тесты для всего ?

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

Как только я показываю «живой» прототип клиенту, получаю отзывы и обсуждаю варианты, мы пытаемся формализовать взаимопонимание для того, что ему действительно нужно. Затем я пишу тематические рассказы для него.

Ресурсы

Лучшие ресурсы, которые я использовал, чтобы узнать больше о теме, которую я обсуждал здесь, были The RSpec Boook и The Cucumber Book . Я продолжаю слышать хорошие вещи о спецификации по примерам , так что это в моем списке «для чтения».

Чем ты занимаешься?

Я хотел бы узнать о вашем опыте тестирования, SubSpec, RSpec, Cucumber, TDD, BDD … Все, что мы затронули в этом сообщении в блоге, действительно. Что сработало для вас? Что не сделал? Почему? Какой опыт вы пробовали? Часто я слышу, как люди говорят: «Я попробовал это испытание, но у меня это не сработало». Ну, этого не достаточно. Было бы здорово узнать, как именно человек попробовал это сделать, какой тип приложения, язык, клиент, контекст и т. Д. Я знаю, что несколько попыток не работали, но я бы поговорил со сверстниками о своем опыте. и чаще всего мы не определяем вероятные причины того, почему это не сработало, поэтому я мог внести исправления и повторить попытку. 🙂