ruby-on-rails – 如何保持RSpec测试的可管理性

概述为了学习RoR,我开始使用优秀的 Rails Tutorial.到目前为止一直都很好,虽然我注意到RSpec测试很快变得混乱.下面是sessions_controller.rb的集成测试示例.随着我的继续,它只会变得更长. 是否有合理的方法将这些测试分解并分解为更小的块？你会如何根据什么标准去做？例子非常受欢迎. 例： require 'spec_helper'describe "Authen 为了学习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 @R_207_4034@ 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  endend

解决方法 好吧,看到你已经使用了必须的RSpec(是吗？),我认为你已经实现了高水平的可读性和可管理性.您可以随时将此规范拆分为较小的部分,但您必须问自己是否真的需要拆分一个控制器的测试代码？你有许多描述部分,它们在结构化测试方面很好.如果有任何失败,RSpec将始终为您提供确切的行号,以便您可以直接进入并修复它.

至于额外的可读性,我注意到在描述部分后使用空行.有些人喜欢在结束语句之前插入空白行.我还建议用end语句编写你要结束的块,如下所示：

describe "GET /posts" do#[...]end #     GET /posts

对于这样结构化的部分,许多编辑器中也有一个很好的功能,它允许代码在这些块内缩小,隐藏代码并在描述之后显示结束.我相信你会自己排序这个.我从来没有想过额外的可读性或基本的东西,我可以管理我写得很好的测试.

希望能说服您已经有一个很好的方法来组织代码.我不认为针对相同功能/对象/目标的拆分测试只是将它保持在< 100行左右. 更新 我最近阅读了article,其中DHH声明RSpec是不必要的复杂,并且测试/单元是可读且易于维护的.我以为你可能想知道这一点.

总结

以上是内存溢出为你收集整理的ruby-on-rails – 如何保持RSpec测试的可管理性全部内容，希望文章能够帮你解决ruby-on-rails – 如何保持RSpec测试的可管理性所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。