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
А в заключение могу только сказать могу только сказать — старайтесь меньше повторяться.
