Тестирование RESTfull api приложения на RoR 5 c Minitest

Далее выполню в терминале команду

rake db:test:prepare

В результате будет создана (если еще не была) тестовая база данных test.sqlite3 в каталоге app/db, которая заполнится данными из фикстур. Теперь можно делать тесты.

Тестирование моделей.

Как я уже упоминал выше: тестируя модели, я буду выполнять так называемое юнит-тестирование, проверять работоспособность кода в одном конкретном файле. Первой будет модель Category. Проверять

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

app/test/models/category_test.rb

require 'test_helper'

class CategoryTest < ActiveSupport::TestCase

  test "category should not save without name" do
    category = Category.new
    assert_not category.save, 'saved category without name'
  end

  test "category should save with name" do
    category = Category.new
    category.name = 'Cat11'
    assert category.save, 'Did NOTsaved category with name'
  end

  test 'deleting category should delete its products' do
    category = Category.create(name:"Cat12")
    product = category.products.create({name:"product1",price:10})
    product_id = product.id
    category.destroy

    assert_raises (ActiveRecord::RecordNotFound) {Product.find(product_id)}
  end
end

Несколько слов про синтаксис. Класс CategoryTest наследует от ActiveSupport::TestCase, который наследует от Minitest::Test. В результате стали доступны  методы проверки утверждений assert. Метод test 'описание теста' создает процедуру test_описание_теста, которая потом и запускается. Каждый тест я мог бы написать и так

def test_category_should_not_save_without_name do
   # тут пишу действия теста
end

По сути, каждый test '' - это один атомарный шаг сценария. Шаги могут объединяться в связанные сценарии для проверки какого-то сценария действий пользователя. А сценарии могут объединяться в одном feature файле (например, category_test.rb), который проверяет конкретную область (функциональность) приложения.

Суть таких объединений, на мой взгляд, это широта изолированного контекста.

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

При создании фича файла с несколькими сценариями контекст можно, конечно, сделать общим между сценариями, но это скорее всего "что-то пошло не так" в планировании тестов. Общий тут смысловой контекст для тестировщика, например, тестируем работу корзины и создаем несколько сценариев в одном файле cart_test.rb. И когда что-то сломалось в работе корзины, нужно будет искать упавший тест только в этом файле и с ним работать.

Для тестирования моделей достаточно будет объединить несколько атомарных test в одном файле для каждой модели.

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

Во втором тесте я проверяю, что новая категория запишется (метод assert) с указанием обязательных полей. Казалось бы, это лишний тест. Однако, если в будущем я расширю список обязательных полей, то этот тест упадет и напомнит мне покрыть тестами новые ограничения.

В третьем тесте я проверяю параметр dependent: :destroy в модели. При удалении категории все ее продукты также должны быть удалены. Есть несколько вариантов проверить что продукт был удален, один из них это словить исключение при попытке найти в базе несуществующую запись (assert_raises).

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

Тестируем дальше.

app/test/models/product_test.rb

require 'test_helper'

class ProductTest < ActiveSupport::TestCase
  test "Product chould not be saved without name and price" do
    category = categories(:one)
    product  = category.products.new
    assert_not product.save, "saved product wothout name"
    product.name = "prod1"
    assert_not product.save, "saved product without price"
  end

  test "Product chould not be saved with price equal zero" do
    category = categories(:one)
    product  = category.products.new
    product.name  = "prod1"
    product.price = 0
    assert_not product.save, "saved product with zero price"
  end

  test "Product chould be saved with name and price greater than zero" do
    category = categories(:one)
    product  = category.products.new
    product.name  = "prod1"
    product.price = 1.1
    assert product.save, "Did NOTsaved product with name and price"
  end
end

Тут мне понадобятся те самые фикстуры, которые я делал чуть выше.

Строка require 'test_helper' загружает файл test_helper.rb, который все фикстуры в виде коллекций помещает в переменные по имени файла фикстуры. Так, например, для доступа к фикстурам категорий, я использую коллекцию categories, в которой по имени конкретного элемента получаю категорию category = categories(:one).

В этих тестах я так же проверяю валидацию.

Тестирование контроллеров.

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

• маршруты (routing), удалось ли по маршруту дойти до действия контроллера
• возвращаемые контроллером ответы и статусы

Первым будет контроллер categories_controller. Для него сгенерирую categories_controller_test.rb.

В терминале набираю

rails g test_unit:scaffold categories

и

rails g test_unit:scaffold products

В результате получаю файл с почти готовыми набросками тестов для каждого действия (action) контроллера. Мне осталось их чуть чуть дописать для моего случая.

Что тут добавилось нового?

Во-первых, это класс, от которого наследуется мой класс class CategoriesControllerTest < ActionDispatch::IntegrationTest.
ActionDispatch::IntegrationTest создан для интеграционного тестирования нескольких частей приложения (как не трудно догадаться) - маршрутизации и контроллеров. Это дает возможность имитировать запросы из вне, оставаясь в своей "песочнице".

Я говорю про методы get, post, delete и т.д, а также методы проверки утверждений assert_difference и assert_response.

Также в классе стали доступны переменные @controller, @request и @response

Во-вторых, появился блок setup do ... end. Этот блок выполняется каждый раз перед запуском очередного test, устанавливая таким образом одинаковый контекст, чтобы не писать поиск категории в каждом тесте.

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

В-четвертых, в каждом тесте проверяется правильно ли был вызван метод (action) контроллера assert_equal "index", @controller.action_name

В-пятых, для проверки json, который возвращает контроллер я использовал гем gem "assert_json", который дает возможность красиво проверять строки json на наличие в них нужных ключей, их значений и отсутствия чего-то лишнего.

Чтобы мне стали доступны возможности этого гема, в начале определения класса я пишу include AssertJson.
Теперь мне доступен метод assert_json(), has_only() для проверки отсутствия лишних ключей, item() для отбора конкретного элемента массива, has() для проверки наличия ключа и его значения.

Более подробно про этот гем смотреть тут.