为了学习RoR,我开始使用出色的Rails Tutorial。到目前为止,到目前为止还不错,尽管我注意到RSpec测试正在迅速变得混乱。以下是sessions_controller.rb集成测试的示例。随着我的不断前进,它只会变得更长。
是否有逻辑方法将这些测试分成较小的块?您将如何处理?基于什么标准?例子是最受欢迎的。
例:
require 'spec_helper'
describe "AuthenticationPages" do
subject { page }
describe "signin" do
before { visit signin_path }
it { should have_selector('h1', text: 'Sign in') }
it { should have_selector('title', text: full_title('Sign in')) }
describe "with invalid information" do
before { click_button "Sign in" }
it { should have_selector('title', text: full_title('Sign in')) }
it { should have_selector('div.flash.error', text: 'Invalid') }
it { should_not have_link('Profile', href: signout_path ) }
it { should_not have_link('Settings', href: edit_user_path) }
describe "after visiting another page" do
before { click_link "Home" }
it { should_not have_selector('div.flash.error') }
end
end
describe "with valid information" do
let(:user) { FactoryGirl.create(:user) }
before do
fill_in "Email", with: user.email
fill_in "Password", with: user.password
click_button "Sign in"
end
it { should have_selector('title', text: user.name) }
it { should have_link('Profile', href: user_path(user)) }
it { should have_link('Settings', href: edit_user_path(user)) }
it { should have_link('Users', href: users_path) }
it { should have_link('Sign out', href: signout_path) }
it { should_not have_link('Sign in', href: signin_path) }
describe "visiting the sign up page" do
before { visit sign_up_path }
it { should_not have_selector('h1', text: 'Sign Up') }
it { should_not have_selector('title', text: full_title('Sign Up')) }
end
describe "submitting to the create action" do
before { post users_path(user) }
specify { response.should redirect_to(user_path(user)) }
end
describe "followed by signout" do
before { click_link "Sign out" }
it { should have_link('Sign in') }
end
end
end
describe "authorization" do
describe "for non-signed-in users" do
let(:user) { FactoryGirl.create(:user) }
describe "in the users controller" do
describe "visiting the edit page" do
before { visit edit_user_path(user) }
it { should have_selector('title', text: 'Sign in') }
end
describe "submitting to the update action" do
before { put user_path(user) }
specify { response.should redirect_to(signin_path) }
end
end
describe "visiting user index" do
before { visit users_path }
it { should have_selector('title', text: 'Sign in') }
end
describe "when attempting to visit a protected page" do
before do
visit edit_user_path(user)
sign_in user
end
describe "after signing in" do
it "should render the desired protected page" do
page.should have_selector('title', text: 'Edit user')
end
describe "when signing in again" do
before do
visit signin_path
sign_in user
end
it "should render the default (profile) page" do
page.should have_selector('title', text: user.name)
end
end
end
end
end
describe "as wrong user" do
let(:user) { FactoryGirl.create(:user) }
let(:wrong_user) { FactoryGirl.create(:user, email: "wrong@example.com") }
before { sign_in user }
describe "visiting users#edit page" do
before { visit edit_user_path(wrong_user) }
it { should have_selector('title', text: 'Sample App') }
end
describe "submitting a PUT request to the users#update action" do
before { put user_path(wrong_user) }
specify { response.should redirect_to(root_path) }
end
end
describe "as non-admin user" do
let(:user) { FactoryGirl.create(:user) }
let(:non_admin) { FactoryGirl.create(:user) }
before { sign_in non_admin }
describe "submitting a DELETE request to the Users#destroy action" do
before { delete user_path(user) }
specify { response.should redirect_to(root_path) }
end
end
end
end
最佳答案
好吧,看到您已经将RSpec与Shoulda一起使用了(是吗?),我认为您已经实现了较高的可读性和可管理性。您总是可以将此规范拆分为较小的部分,但是您必须问自己,是否真的有必要将一个控制器的测试代码拆分?您有很多describe
部分,它们很擅长于结构化测试。如果发生任何故障,RSpec始终会为您提供确切的行号,以便您可以直接跳进来进行修复。
至于额外的可读性,我注意到您在describe
部分后使用空白行。有些人还喜欢在end
语句之前插入空白行。我还建议编写以end
语句结尾的块,如下所示:
describe "GET /posts" do
#[...]
end # GET /posts
由于部分的结构是这样的,因此许多编辑器中都有一个很好的功能,它可以通过隐藏代码并在
end
之后显示describe
来缩小块内的代码。相信您会自行整理。我从未考虑过额外的可读性或除基础之外的任何内容,并且我可以管理我编写的所有测试。希望这可以说服您,您已经拥有了一种组织代码的好方法。我认为将针对相同功能/对象/目标的测试分开只是为了使其保持在
< 100
行左右是没有任何意义的。更新资料
我最近读了一个article,其中DHH指出RSpec不必要地复杂,并且
test/unit
可读且易于维护。我以为你可能想知道这一点。