Тестовый пример контроллера действий

Суперкласс для функциональных тестов ActionController. Функциональные тесты позволяют проверять одно действие контроллера в каждом тестовом методе.

Используйте интеграционные тесты контроллеров вместо функциональных.

Rails не рекомендует использовать функциональные тесты вместо интеграционных (используйте ActionDispatch::IntegrationTest).

Новые приложения Rails больше не генерируют функциональные тесты контроллеров, и их следует использовать только для обратной совместимости. Интеграционные тесты контроллеров выполняют реальные запросы, тогда как функциональные тесты контроллеров лишь имитируют запрос. Кроме того, интеграционные тесты работают так же быстро, как функциональные, и предоставляют множество вспомогательных средств, таких как as, parsed_body, для эффективного тестирования действий контроллера, включая даже конечные точки API.

Простой пример

Функциональные тесты пишутся следующим образом: 1. Сначала используется метод get, post, patch, put, delete или head для имитации HTTP-запроса. 2. Затем проверяется, соответствует ли текущее состояние ожидаемому. «Состоянием» может быть что угодно: HTTP-ответ контроллера, содержимое базы данных и т. д.

Например:

class BooksControllerTest < ActionController::TestCase
  def test_create
    # Simulate a POST response with the given HTTP parameters.
    post(:create, params: { book: { title: "Love Hina" }})

    # Asserts that the controller tried to redirect us to
    # the created book's URI.
    assert_response :found

    # Asserts that the controller really put the book in the database.
    assert_not_nil Book.find_by(title: "Love Hina")
  end
end

Вы также можете отправить настоящий документ в имитируемом HTTP-запросе.

def test_create
  json = {book: { title: "Love Hina" }}.to_json
  post :create, body: json
end

Специальные переменные экземпляра

ActionController::TestCase также автоматически предоставляет следующие переменные экземпляра для использования в тестах:

@controller

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

@request

Объект ActionController::TestRequest, представляющий текущий HTTP-запрос. Вы можете изменить этот объект перед отправкой HTTP-запроса. Например, перед отправкой GET-запроса можно задать некоторые свойства сессии.

@response

Объект ActionDispatch::TestResponse, представляющий ответ на последний HTTP-запрос. В приведённом выше примере @response становится доступным после вызова post. Если различных методов assert недостаточно, вы можете использовать этот объект для подробного изучения HTTP-ответа.

Контроллер определяется автоматически

ActionController::TestCase автоматически определяет тестируемый контроллер по имени класса теста. Если контроллер нельзя определить по имени класса теста, его можно задать явно с помощью tests.

class SpecialEdgeCaseWidgetsControllerTest < ActionController::TestCase
  tests WidgetController
end

Внутренние механизмы контроллера

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

• session: объекты, сохраняемые в сессии.

• flash: объекты flash, находящиеся в текущий момент в сессии.

• cookies: Cookies, отправляемые пользователю в этом запросе.

Эти коллекции можно использовать так же, как любой другой хэш:

assert_equal "Dave", cookies[:name] # makes sure that a cookie called :name was set as "Dave"
assert flash.empty? # makes sure that there's nothing in the flash

Кроме того, полный URL-адрес, на который перенаправило заданное действие, доступен в redirect_to_url.

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

Изменение переменных сессии и cookie

Иногда для теста требуется задать переменные сессии и cookie. Для этого просто присвойте значение коллекции сессии или cookie:

session[:key] = "value"
cookies[:key] = "value"

Чтобы очистить cookie для теста, просто очистите коллекцию cookie:

cookies.clear

Тестирование именованных маршрутов

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

assert_redirected_to page_url(title: 'foo')