DRY(Don’t Repeat Yourself) — один из краеугольных принципов современной разработки, а особенно в среде ruby-программистов. Но если при написании обычного кода повторяющиеся фрагменты обычно легко можно сгруппировать в методы или отдельные модули, то при написании тестов, где повторяющегося кода порой еще больше, это сделать не всегда просто. В данной статье содержится небольшой обзор средств решения подобных проблем при использовании BDD-фреймворка RSpec.
1. Shared Examples
Самый известный и часто используемый метод создания многократно используемого кода для Rspec. Отлично подходит для тестирования наследования классов и включений модулей.
shared_examples "coolable" do
let(:target){described_class.new}
it "should make cool" do
target.make_cool
target.should be_cool
end
end
describe User do
it_should_behave_like "coolable"
end
Кроме того Shared Example Groups обладают и некоторым дополнительным функционалом, что делает их гораздо более гибкими в использовании: передача параметров, передача блока и использование let в родительской группе для определения методов.
shared_examples "coolable" do |target_name|
it "should make #{ target_name } cool" do
target.make_cool
target.should be_cool
end
end
describe User do
it_should_behave_like "coolable", "target user" do
let(:target){User.new}
end
end
Подробнее о том, где и как будут доступны определенные методы, можно прочитать у Дэвида Челимски[2].
2. Shared Contexts
Данная фича несколько малоизвестна в силу своей относительной новизны(появилась в RSpec 2.6) и узкой области применения. Наиболее подходящей ситуацией для использования shared contexts является наличие нескольких спеков, для которых нужны одинаковые начальные значения или завершающие действия, обычно задаваемые в блоках before и after. На это намекает и документация:
shared_context "shared stuff", :a => :b do
before { @some_var = :some_value }
def shared_method
"it works"
end
let(:shared_let) { {'arbitrary' => 'object'} }
subject do
'this is the subject'
end
end
Очень удобной вещью в shared_context является возможность их включения по метаинформации, заданной в блоке describe:
shared_context "shared with somevar", :need_values => 'some_var' do
before { @some_var = :some_value }
end
describe "need som_var", :need_values => 'some_var' do
it “should have som_var” do
@some_var.should_not be_nil
end
end
3. Фабрики объектов
Еще один простой, но очень важный пункт.
@user = User.create(
:email => ‘example@example.com’,
:login => ‘login1’,
:password => ‘password’,
:status => 1,
…
)
Вместо многократного написания подобных конструкций следует использовать гем factory_girl или его аналоги. Преимущества очевидны: уменьшается объем кода и не нужно переписывать все спеки, если вы решили поменять status на status_code.
4. Собственные матчеры
Возможность определять собственные матчеры — одна из самых крутых возможностей в RSpec, благодаря которой можно нереально повысить читабельность и элегантность ваших спеков. Сразу пример.
До:
it “should make user cool” do
make_cool(user)
user.coolness.should > 100
user.rating.should > 10
user.cool_things.count.should == 1
end
После:
RSpec::Matchers.define :be_cool do
match do |actual|
actual.coolness.should > 100 && actual.rating.should > 10 && actual.cool_things.count.should == 1
end
end
it “should make user cool” do
make_cool(user)
user.should be_cool
end
Согласитесь, стало в разы лучше.
RSpec позволяет задавать сообщения об ошибках для собственных матчеров, выводить описания и выполнять чейнинг, что делает матчеры гибкими настолько, что они просто ничем не отличаются от встроенных. Для осознания всей их мощи, предлагаю следующий пример[1]:
RSpec::Matchers.define :have_errors_on do |attribute|
chain :with_message do |message|
@message = message
end
match do |model|
model.valid?
@has_errors = model.errors.key?(attribute)
if @message
@has_errors && model.errors[attribute].include?(@message)
else
@has_errors
end
end
failure_message_for_should do |model|
if @message
"Validation errors #{model.errors[attribute].inspect} should include #{@message.inspect}"
else
"#{model.class} should have errors on attribute #{attribute.inspect}"
end
end
failure_message_for_should_not do |model|
"#{model.class} should not have an error on attribute #{attribute.inspect}"
end
end
5. Однострочники
RSpec предоставляет возможность использования однострочного синтаксиса при написании простых спеков.
Пример из реального opensource-проекта(kaminari):
context 'page 1' do
subject { User.page 1 }
it { should be_a Mongoid::Criteria }
its(:current_page) { should == 1 }
its(:limit_value) { should == 25 }
its(:total_pages) { should == 2 }
it { should skip(0) }
end
end
Явно гораздо лучше, чем:
context 'page 1' do
before :each do
@page = User.page 1
end
it “should be a Mongoid criteria” do
@page.should be_a Mongoid::Criteria
end
it “should have current page set to 1” do
@page.current_page.should == 1
end
….
#etc
6. Динамически создаваемые спеки
Ключевым моментом здесь является то, что конструкция it (как впрочем и context и describe) является всего лишь методом, принимающим блок кода в качестве последнего аргумента. Поэтому их можно вызывать и в циклах, и в условиях, и даже составлять подобные конструкции:
it(it("should process +"){(2+3).should == 5}) do
(3-2).should == 1
end
Оба спека кстати проходят успешно, но страшно даже подумать, где такое можно применить, в отличие от тех же циклов и итераторов. Пример из той же Kaminari:
[User, Admin, GemDefinedModel].each do |model_class|
context "for #{model_class}" do
describe '#page' do
context 'page 1' do
subject { model_class.page 1 }
it_should_behave_like 'the first page'
end
…
end
end
end
Или же пример с условиями:
if Mongoid::VERSION =~ /^3/
its(:selector) { should == {'salary' => 1} }
else
its(:selector) { should == {:salary => 1} }
end
7. Макросы
В 2010 году, после введения нового функционала shared examples, Дэвид Челимски заявил, что макросы больше не нужны. Однако если вы все же считаете, что это наиболее подходящий способ улучшить код ваших спеков, вы можете создать их примерно так:
module SumMacro
def it_should_process_sum(s1, s2, result)
it "should process sum of #{s1} and #{s2}" do
(s1+s2).should == result
end
end
end
describe "sum" do
extend SumMacro
it_should_process_sum 2, 3, 5
end
Более подробно останавливаться на этом пункте смысла не вижу, но если вам захочется, то можно почитать [4].
8. Let и Subject
Конструкции let и subject нужны для инициализации исходных значений перед выполнением спеков. Конечно все и так в курсе, что писать так в каждом спеке:
it “should do something” do
user = User.new
…
end
совсем не здорово, но обычно все пихают этот код в before:
before :each do
@user = user.new
end
хотя следовало бь для этого использовать subject. И если раньше subject был исключительно “безымянным”, то теперь его можно использовать и в явном виде, задавая имя определяемой переменной:
describe "number" do
subject(:number){ 5 }
it "should eql 5" do
number.should == 5
end
end
Let схож с subject’ом, но используется для объявления методов.
Дополнительные ссылки
1. Custom RSpec-2 Matchers
solnic.eu/2011/01/14/custom-rspec-2-matchers.html
2. David Chelimsky — Specifying mixins with shared example groups in RSpec-2
blog.davidchelimsky.net/2010/11/07/specifying-mixins-with-shared-example-groups-in-rspec-2/
3. Ben Scheirman — Dry Up Your Rspec Files With Subject & Let Blocks
benscheirman.com/2011/05/dry-up-your-rspec-files-with-subject-let-blocks
4. Ben Mabey — Writing Macros in RSpec
benmabey.com/2008/06/08/writing-macros-in-rspec.html
А в заключение могу только сказать могу только сказать — старайтесь меньше повторяться.
Автор: rsludge
