【问题标题】:What should I be testing in my rails application's model when using devise? [closed]使用设计时,我应该在我的 Rails 应用程序模型中测试什么? [关闭]
【发布时间】:2014-09-28 00:55:11
【问题描述】:

希望这是一个简单的问题...

我看到这个设计看起来经过了很好的测试,但我宁愿安全而不是抱歉。设计者自己的测试尚未涵盖的模型规范中需要测试的最少项目是什么?

使用 ruby​​ 2.1.2、rails 4.1.6、rspec-rails 3.1.0 和 devise 3.3.0。目前我的模型规格如下:

describe User do
  before(:each) { @user = create(:user) }

  subject { @user }

  describe "factory" do
    it { should be_valid }
  end

  describe "class instance" do
    it { should respond_to(:email) }
    it { should respond_to(:encrypted_password) }
    it { should respond_to(:reset_password_token) }
    it { should respond_to(:reset_password_sent_at) }
    it { should respond_to(:remember_created_at) }
    it { should respond_to(:sign_in_count) }
    it { should respond_to(:current_sign_in_at) }
    it { should respond_to(:last_sign_in_at) }
    it { should respond_to(:current_sign_in_ip) }
    it { should respond_to(:last_sign_in_ip) }
    it { should respond_to(:created_at) }
    it { should respond_to(:updated_at) }
    it { should respond_to(:name) }
  end

  describe "name" do
    context "when it's not present" do
      before { @user.name = " " }
      it { should_not be_valid }
    end

    context "when it's too long" do
      before { @user.name = "a" * 51 }
      it { should_not be_valid }
    end

    context "when it's long enough" do
      before { @user.name = "a" * 50 }
      it { should be_valid }
    end
  end

  describe "email" do
    context "when it's not present" do
      before { @user.email = " " }
      it { should_not be_valid }
    end

    context "when it's format is invalid" do
      it "should not be valid" do
        addresses = %w[user@foo,com user_at_foo.org example.user@foo. foo@bar..com]
        addresses.each do |invalid_address|
          @user.email = invalid_address
          expect(@user).not_to be_valid
        end
      end
    end

    context "when it's format is valid" do
      it "should be valid" do
        addresses = %w[user@foo.COM A_US-ER@f.b.org frst.lst@foo.jp a+b@baz.cn]
        addresses.each do |valid_address|
          @user.email = valid_address
          expect(@user).to be_valid
        end
      end
    end

    context "when it's already taken" do
      let(:new_user) { create(:user) }

      before { @user = build(:user, email: new_user.email) }
      it { should_not be_valid }
    end

    context "address with mixed case" do
      let(:mixed_case_email) { "Foo@ExAMPle.CoM" }

      it "should be saved as all lower-case" do
        @user.email = mixed_case_email
        @user.save
        expect(@user.email).to eq mixed_case_email.downcase
      end
    end
  end

  describe "password" do
    context "when it's not present" do
      before { @user.password = @user.password_confirmation = " " }
      it { should_not be_valid }
    end

    context "when it doesn't match the password confirmation" do
      before { @user.password_confirmation = "mismatch" }
      it { should_not be_valid }
    end

    context "when it's too short" do
      before { @user.password = @user.password_confirmation = "a" * (Rails.application.config.devise.password_length.min - 1) }
      it { should_not be_valid }
    end
  end
end

省略了包括 factory_girl 方法、实际工厂配置(包括 rails/spec_helper)和其他设置/配置选项之类的内容...请告诉我是否应该包括这些或任何其他项目以帮助澄清。

【问题讨论】:

    标签: ruby-on-rails rspec devise


    【解决方案1】:

    我测试通过第三方代码实现的功能的方法可能包括三道防线:

    1. 在执行任何操作之前测试模型有效性。您已经在 describe "factory" 规范中做到了这一点。
    2. 测试模型验证是否按预期工作。这通常感觉有点矫枉过正,但它对于回归测试很有价值,而且我偶尔会从过于宽泛或过于狭窄的验证中发现错误。不管怎样,你也做到了。
    3. 编写验收测试表明登录、注销、重置密码等关键应用程序级交互按预期工作。为此,您需要使用 Capybara 或类似的东西。

    【讨论】:

    • 我猜验收测试应该在功能规范中完成,不是吗?
    • 是的,完全正确。它可以是标准的 Rails 集成测试,也可以使用 Capybara 或其他等价物。以与浏览器中的最终用户相同的方式运行整个应用程序的任何内容。
    猜你喜欢
    • 2018-10-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-11-25
    • 1970-01-01
    相关资源
    最近更新 更多