Рецепты тестирования Ruby и Rails приложений
В этом посте я хотел бы рассказать о подходах, приемах и средствах подготовки тестов. Расскажу про то, как не писать лишнего, меньше дублировать код, писать тесты так, чтобы их было легко поддерживать, и как выигрывать в производительности в некоторых ситуациях.
Кому это будет интересно?
- Если вы начали писать тесты недавно.
- Если вы пишете тесты и считаете, что в них много копипасты, или можно значительно улучшить их.
- Если вы пишете тесты изредка или не пишете совсем, так как вам не нравится или считаете, что это долго.
- Если вы мастер в написании тестов. Возможно, вы узнаете некоторые тонкости или найдете несколько полезных мелочей.
Примеры кода я буду приводить для RSpec, но большинство из них будут работать и с MiniTest (некоторые надо будет довести напильником). Тем, кто пользуется RSpec, но еще не читал betterspecs.org, советую посмотреть — там на примерах продемонстрировано, как писать хорошо, и как писать не надо.
На каждый день
RSpec DSL
RSpec на самом деле создает класс для каждого контекста. Это значит, что вы можете объявлять инстанс- и класс-методы в тексте спека и использовать их во всех вложенных контекстах. Есть несколько хэлперов, которые в этом помогут.let
В RSpec let является предпочтительным способом задания локальных «переменных». Он определяет новый инстанс-метод, который возвращает результат блока, вычесленный в контексте теста. Вычисляется результат лениво, поэтому нет ничего страшного, если вы определили `let` и не использовали его в части тестов — на время тестирования это не повлияет. Блок одного let может использовать результат другого let или результат из внешнего контекста через super:
let(:project) { Project.new(project_attrs) }
let(:project_attrs) { {name: 'new_name', description: 'new_description'} }
context 'when empty name is given' do
let(:project_attrs) { super().merge!(name: '') }
# В текущей версии ruby super в этом случае нужно вызывать, явно указывая аргументы.
# Тут их нет, поэтому ().
end
При использовании let следует обратить внимание на то, что результат блока кэшируется на время выполнения примера. Определяемые им значения — это, фактически, константы на время теста. Поэтому let не подходит для создания шорткатов. Если предполагается, что значение будет меняться, то правильно будет объявить метод.subject
subject — это «особенный» let. Главная особенность в том, что все матчеры, у которых не указан получатель, применяются к subject.
describe '#valid?' do
subject { user.valid? }
it { should eq true }
# или
it { is_expected.to eq true }
# subject можно использовать и c привычными матчерами
context 'when name is empty' do
it 'adds error' do
expect { subject }.to change(user.errors, :any?).to true
end
end
end
Использование subject уменьшает количество дублируемого кода, повышает читабельность и позволяет определить ситуации, когда вы тестируете функционал, отличный от указанного в describe. В большинстве случаев вам удастся использовать единственный subject на describe, влияя на его поведение с помощью let во вложенных контекстах:
# Пример теста контроллера
RSpec.describe ProjectsController do
describe '#index' do
subject { get :index }
it { should redirect_to new_user_session_path }
context 'for signed in user' do
sign_in { create(:user) } # хэлпер, чтобы залогинить пользователя
it { should be_forbidden }
context 'with permissions' do
add_permissions(:manager) # хэлпер для добавления прав залогиненому пользователю
it { should be_ok }
end
end
end
# Тут и ниже опустим авторизацию для экономии места
describe '#create' do
subject { post :create, project: resource_params }
let(:resource_params) { {name: 'new_project'} }
it 'creates resource and redirects to its page' do
expect { subject }.to change(Project, :count).by(1)
resource = Project.last
expect(project.name).to eq 'new_name'
expect(subject).to redirect_to project_path(resource)
end
context 'when params are invalid' do
let(:resource_params) { super().merge!(name: '') }
it { should render_template :new }
it 'doesnt create resource' do
expect { subject }.to_not change(Project, :count)
end
end
end
end
В тестах `type: :request` get, post и другие методы не возвращают response. Но можно немного поправить наш subject, чтобы использовать в них такой же подход:
subject do
get '/projects'
response
end
До этого в subject мы помещали выражение, результат которого проверяли. Часто бывает, что проверок результата гораздо меньше, чем проверок того, что состояние системы изменилось. В таких случаях помогают лямбды:
describe '#like!' do
subject { -> { user.like! post } }
it { should change(post, :likes_count).by(1) }
it { should change(user, :favorite_posts).by(post) }
context 'when post is already favorite' do
before { subject.call }
it { should raise_error /Already favorite/ }
end
end
Лямбды удобны также в тех случаях, когда нужно проверить результат метода на большом количестве входных данных, и нет смысла создавать контекст под каждый вариант:
describe '.cleanup_str' do
subject { ->(*args) { described_class.cleanup_str(*args) } }
it 'removes non-word symbols' do
expect(subject.call('xY12')).to eq 'xY12'
expect(subject.call('x+Y-1_2')).to eq 'xY12'
expect(subject.call('x.Y 1;2')).to eq 'xY12'
end
end
Обратите внимание, что во всех примерах мы не обращаемся к тестируемому методу, кроме как через subject.its
Для RSpec есть отличный плагин rspec-its, который вынесли в отдельный гем в третьей версии. C этой штукой тесты могут стать ещё компактнее и выразительнее. Вот пример, где its точно бы пригодился.
Не совсем очевидный, но очень полезный приём — использование its с лямбдами:
RSpec.describe ProjectsController do
let(:resource) { create(:project) }
describe '#update' do
subject { -> { patch :update, id: project, project: resource_params } }
let(:resource_params) { {name: 'updated_name'} }
it { should change { resource.reload.name }.to 'updated_name' }
its(:call) { should redirect_to project_path(resource) }
end
end
Ещё одна ситуация, где its очень пригодился — при проверке JSON ответов. Если определить метод ActionDispatch::TestResponse#json_body, который пропускает #body через JSON.parse и превращает результат в Mash (например, так), то проверять поля становится очень удобно:
RSpec.describe UsersController do
let(:resourse) { create(:user) }
describe '#show' do
subject { get :show, id: resource, format: :json }
its('json_body.keys') { should contain_exactly(*w(name projects avatar)) }
its('json_body.avatar.keys') { should contain_exactly(*w(url size)) }
its('json_body.projects.first.keys') { should contain_exactly(*w(name created_at)) }
end
end
described_class
described_class — ещё один «особенный» let. Это хэлпер для доступа к объекту, который вы указали в RSpec.describe. При использовании его вместо явного указания модуля код получается «обособленный»: класс как аргумент describe, и обращение к нему происходит как к аргументу. Такой код более пригоден для повторного использования, его, например, проще выделять в shared_examples. described_class без проблем работает и с константами: should raise_error described_class::Error, или described_class::LIMIT.Именование переменных
Попробуйте использовать общие нейтральные названия для некоторых переменных во всех тестах. Мы, например, используем instance для обозначения экземпляров тестируемых классов и resource для обозначения обрабатываемого ресурса в тестах контроллеров/запросов. Объективных плюсов такого подхода я назвать не могу, но субъективно тесты пишутся и читаются быстрее.shared_examples
Локальные shared_examples можно определить внутри любого контекста, и они не будут доступны вне этого контекста. Это удобно использовать, когда проверки нужно повторить проверки в нескольких вложенных контекстах:
RSpec.describe ProjectsController do
let(:resource) { create(:project) }
shared_examples 'rendering resource' do
it { should be_ok }
its(:json_body) { should include 'id' => resource.id, 'name' => resource.name }
end
describe '#show' do
subject { get :show, id: resource.id }
include_examples 'rendering resource'
end
describe '#search' do
subject { get :search, q: resource.name }
include_examples 'rendering resource'
end
Иногда при использовании shared_examples нужно добавить специальные проверки только в определенных случаях или дать возможность заменить одни проверки другими для некоторых тестов. В таких случаях можно разделить крупные блоки shared_examples на отдельные поменьше и копировать контексты между файлами. Но можно передать нужные проверки в параметрах к include_examples:
RSpec.shared_examples 'hooks controller #create' do |**options|
describe '#create' do
subject { post :create, params }
context 'on success' do
let(:params) { valid_params }
# Общие проверки
it { should change { something } }
# Опциональные проверки
instance_eval(&options[:on_success]) if options[:on_success]
end
context 'on failure' do
let(:params) { invalid_params }
it { should_not change { something } }
if options[:on_failure]
instance_eval(&options[:on_failure])
else
its(:status) { should eq 422 } # дефолтное поведение
end
end
end
end
RSpec.describe BrandedHooksController do
include_examples 'hooks controller #create',
on_success: -> { its(:json_body) { should eq 'status' => 'ok' } },
on_failure: -> { its(:json_body) { should eq 'status' => 'rejected' } } do
let(:valid_params) { {type: 'hook'} }
let(:invalid_params) { {type: 'unsupported'} }
end
end
Ускоряем тесты
Я не буду писать про spring/zeus/spork/др., а расскажу, как ещё в некоторых ситуациях можно сократить время тестирования.Отключите долгие тесты
:) Но не совсем. Конечно, такой подход может не подойти по многим причинам, но если у вас есть задачи, требующие долгих вычислений, пометьте их тэгом в RSpec и отключите их выполнение при обычном запуске rspec. Это могут быть вызовы внешних приложений, долгие запросы в БД, работа с большими файлами.
# spec_helper.rb
# Exclude some tags by default. Running 1 file won't use exclusions.
# Use `FULL=true bin/rspec` to disable filters.
if (!ENV.key?('FULL') || !ENV.key?('CI')) && config.files_to_run.size > 1
config.filter_run_excluding :external, :elastics
end
# some_job_spec.rb
describe '.process_file', :external do
it 'does somithing heavy'
end
С такими настройками тесты джобы не будут выполняться каждый раз, но будут выполены, если вы запустите:
- только один файл
some_job_spec.rb - `FULL=true bin/rspec`
- на CI сервере (если установлена envar CI)
Отключите процессинг изображений
Полагаю, это подойдёт всем, кто его использует. Если вы не используете fixtures, и у вас есть обязательное поле-изображение в модели, то в каждом тесте, который создаёт экземпляр этого класса, будет происходить обработка изображения.
Способ отключения обработки зависит от используемой библиотеки. В тестах же подход будет одинаковым: отключить процессинг для всех тестов и включать его по тэгу или в around-хуке.
module SpecHelpers
# All image uploaders are descendants of ImageUploader. This module
# toggles <code>enable_processing</code> of it and all its descendants.
module ImageProcessing
module_function
# Overwrites cached values in ancestors.
def enable_processing=(val)
ImageUploader.enable_processing = val
ImageUploader.descendants.each { |x| x.enable_processing = val }
end
def with_processing(val)
old_value = ImageUploader.enable_processing
self.enable_processing = val
yield
ensure
self.enable_processing = old_value unless old_value == ImageUploader.enable_processing
end
end
end
# rails_helper.rb
around process_images: true do |ex|
SpecHelpers::ImageProcessing.with_processing(true) { ex.run }
end
Полезные мелочи
- RSpec3 использует
.rspecдля задания дефолтных флагов. После установки в нём есть строка `--require spec_helper`. Если её заменить на `--require rails_helper`, то можно будет не писать `require 'rails_helper'` в каждом спеке. - ^^
# spec_helper.rb require 'bigdecimal' BigDecimal.class_eval do alias_method :inspect_orig, :inspect alias_method :inspect, :to_s end
Спасибо за внимание! Пожалуйста, делитесь вашими рецептами в коментариях.
