因此,在我为我的RoR模型演变的rspecs中,我最终得到了两个完全相同的测试:
it 'is valid when x is zero' do
foo = build(:foo, x: 0, y: 10)
expect(foo.valid?).to be_truthy
end
it 'is valid when y is ten' do
foo = build(:foo, x: 0, y: 10)
expect(foo.valid?).to be_truthy
end
这是因为我首先编写了验证x的规范,然后在y之后添加了规范。
显然,是时候重构了。我可以删除其中一个规格,因为它们是重复的:保持干燥。
现在,每个规范的内部可能完全相同,但it
描述不同。我不想丢失那里的信息。
我的问题是 - 在这种情况下是否可以保持重复的规格不变,或者我是否应该合并'他们并改写it
描述?也许:
it 'is valid when x is zero and y is ten' do
foo = build(:foo, x: 0, y: 10)
expect(foo.valid?).to be_truthy
end
但是在我看来,我现在有一个规范正在测试两件事(Foo模型中的两个验证子句)。这也不好。气味潜伏着。
还有其他方法我错过了吗?
答案 0 :(得分:2)
一般来说,我认为进行小型独立测试比做DRY更重要。
但是,测试逻辑似乎存在不一致。
如果当x为零时foo 总是有效,那么你应该能够在第一个规范中删除y值。
var command = new PSCommand();
command.AddCommand("Invoke-Command");
command.AddParameter("ScriptBlock", ScriptBlock.Create(@"
param(${identity}, ${user})
Get-MailboxPermission -Identity ${identity} -User ${user}
"));
command.AddParameter("ArgumentList", new object[]{mailbox, user});
如果当y为10时foo 总是有效,那么你应该能够删除该规范中的x值。
it 'is valid when x is zero' do
foo = build(:foo, x: 0)
expect(foo.valid?).to be_truthy
end
如果不是这种情况,您可以考虑更具体地测试案例。
例如:
it 'is valid when y is ten' do
foo = build(:foo, y: 10)
expect(foo.valid?).to be_truthy
end
答案 1 :(得分:2)
我不太担心DRY,更多关于编写实际上涵盖你想要的行为的规范。
it 'is valid when x is zero' do
foo = build(:foo, x: 0)
expect(foo.valid?).to be_truthy
end
此示例实际上并不涵盖您的验证!如果您在模型中注释掉验证,它仍然会通过。
测试模型验证时的一些提示:
.new
和正在测试的属性进行初始化。RSpec.describe Foo do
describe "validations" do
describe 'x' do
it "validates that x is a number between 1 and 10" do
expect(Foo.new(500).valid?.errors[:x]).to include "must be less than or equal to 10".
expect(Foo.new(10).valid?.errors).to_not have_key :x
end
end
describe 'y' do
it "validates that y is a number that is less than 15" do
expect(Foo.new(500).valid?.errors[:y]).to include "must be less than 15".
expect(Foo.new(10).valid?.errors).to_not have_key :y
end
end
end
end
答案 2 :(得分:1)
是的,有些情况下可以保留重复测试。
DRY代码实践背后的规则并不是硬性和快速的,而是更多的启发式。保持代码DRY的主要目的之一主要是出于维护目的。有时人们(包括我自己)觉得你正在努力确保你不会为了不重复自己而在任何地方重复自己。如果你发现你为了只写一次东西而增加了不正确的复杂性(我喜欢桑迪梅斯的说法“不那么干,它会让人感到厌烦”)那么你需要问自己“这真的值得付出努力吗?”使我的代码更易读或可维护?“我认为一个测试是一个很好的试金石是你写的重复代码的实例是出于不同的原因编写的,例如这个实例是针对结果的副作用。