Question

我刚刚开始学习BDD / TDD的实践（世界很高兴，我知道）。在这一点上我挣扎的事情之一是哪些测试实际上值得写。让我们为一个名为Sport的模型开始进行这些测试：

Factory.define :sport do |f|
  f.name 'baseball'
end


require 'spec_helper'

describe Sport do

  before(:each) do
    @sport_unsaved = Factory.build(:sport)  # returns an unsaved object
    @sport_saved = Factory.create(:sport) # returns a saved object
  end

  # Schema testing.
  it { should have_db_column(:name).of_type(:string) }
  it { should have_db_column(:created_at).of_type(:datetime) }
  it { should have_db_column(:updated_at).of_type(:datetime) }

  # Index testing.

  # Associations testing.
  it { should have_many(:leagues) }

  # Validations testing.
  it 'should only accept unique names' do
    @sport_unsaved.should validate_uniqueness_of(:name)
  end

  it { should validate_presence_of(:name) }

  it 'should allow valid values for name' do
    Sport::NAMES.each do |v|
      should allow_value(v).for(:name)
    end
  end

  it 'should not allow invalid values for name' do
    %w(swimming Hockey).each do |v|
      should_not allow_value(v).for(:name)
    end
  end

  # Methods testing.

end

我有几个具体问题：

是否值得测试协会sport.leagues返回非空白值？
如果未指定名称，确保模型无效的测试怎么样？
测试如何确保创建有效记录并且没有任何验证错误？

我可以继续。理想情况下，我可以遵循一些严格而快速的规则来指导我的测试工作。但我猜这有经验和良好的实用主义。我已经考虑过阅读几个宝石的源代码，比如rails core，以便更好地理解什么是值得测试和什么不是。

您有经验的测试人员可以提供哪些建议？

Answer 1

如果您只是重新测试Rails行为，那就不行了。
是 - 它是模型验证和要求的一部分，为什么不确保满足要求？
测试您对保存过程的假设是一个好主意，如果有任何生命周期监听器/观察者，他们可能在保存之前不会被解雇。

Rails核心测试不会帮助您确定在应用程序中测试的好主意。

Answer 2

你应该测试什么？任何你不想被打破的东西
何时停止编写测试？当恐惧变成无聊时

因此，如果未显示指定的行为，1,2,3是缺陷，那么您应该对所有3进行测试。

从代码片段开始，我个人不会检查数据库实现（存在哪些列及其详细信息）。原因：我希望能够随着时间的推移改变它，而不必打破一堆测试并修复所有测试。只有在行为被破坏时，测试才会中断。如果您满足它们的方式（实现）发生变化，则测试不应该破坏/需要修改专注于什么超过如何。

HTH

BDD / TDD入门（Rails / Rspec）

2 个答案: