Question

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

我认为设计看起来经过了很好的测试，但我宁愿安全而不是抱歉。在模型规范中需要测试的最小项目是什么，这些项目还没有被设计自己的测试所涵盖？

使用ruby 2.1.2，rails 4.1.6，rspec-rails 3.1.0，＆amp;设计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和其他setup / config选项在内的内容被省略...请告诉我是否应该包含这些或任何其他项目以帮助澄清。

Answer 1

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

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

使用设计时，我应该在rails应用程序的模型中测试什么？

1 个答案: