首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >如何使RSpec测试易于管理

如何使RSpec测试易于管理
EN

Stack Overflow用户
提问于 2012-02-24 02:36:27
回答 1查看 412关注 0票数 4

为了学习RoR,我开始使用优秀的Rails Tutorial。到目前为止一切顺利,尽管我注意到RSpec测试正在迅速变得混乱不堪。下面是sessions_controller.rb集成测试的示例。随着我的继续,它只会变得更长。

有没有一种合理的方法来将这些测试分成更小的块?你将如何去做?基于什么标准?我们非常欢迎这样的例子。

示例:

代码语言:javascript
复制
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
EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2012-02-24 04:34:52

好吧,鉴于您已经将RSpec与shoulda一起使用(对吗?),我认为您已经实现了很高级别的可读性和可管理性。您总是可以将此规范拆分为更小的部分,但您必须问自己,为一个控制器拆分测试代码真的有必要吗?你有很多describe部分,它们本身就很擅长结构化测试。如果任何东西失败了,RSpec总是会给你确切的行号,这样你就可以直接进入并修复它。

至于额外的可读性,我注意到您在describe部分之后使用了空行。有些人还喜欢在end语句前插入空行。我还建议您编写以end语句结尾的块,如下所示:

代码语言:javascript
复制
describe "GET /posts" do
#[...]
end #     GET /posts

有了这样的部分结构,在许多编辑器中也有一个很好的特性,它允许通过隐藏代码并在describe之后显示end来缩小代码块内部。我相信你会自己解决这个问题的。我从来没有考虑过额外的可读性或基础知识之外的任何东西,我可以很好地管理我写的测试。

我希望这能让你确信你已经有了一个很好的方法来组织你的代码。我不认为拆分针对相同功能/对象/目标的测试仅仅为了将其控制在< 100行以下是有任何意义的。

更新

我最近读到了一篇article,其中DHH指出RSpec是不必要的复杂,并且test/unit是可读和易于维护的。我想你可能想知道这个。

票数 4
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/9419084

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档