gpt4 book ai didi

ruby - 如何构造rspec数据测试?

转载 作者:数据小太阳 更新时间:2023-10-29 08:12:26 25 4
gpt4 key购买 nike

背景

我是 Ruby(和 RSpec)的新手,我的应用程序代码会发出一个数据对象。我希望我的规范验证哈希的结构是否正确(即它包含所有必要的键)和数据是否正确(即输入是否正确地与默认值合并)。这是一个简单的例子:

def returns_the_hash
{
:foo => "bar",
:baz => "qux",
:options => {
:oof => "rab",
:zab => "xuq",
},
}
end

稍后需要注意的是,整个哈希是基于输入(我的规范可用)的确定性。我必须做出的选择是如何扩展或紧凑地做出我的断言。假设在这种情况下我只对 :foo:options[:zab] 对感兴趣:

“显式”测试

优点:最好的意图分离

缺点:最冗长;引入了隐藏的依赖关系

it "should be structured properly" do
hsh = returns_the_hash
expect(hsh).to have_key(:foo)
expect(hsh).to have_key(:options)
expect(hsh[:options]).to have_key(:zab)
end

it "should merge inputs with default values" do
hsh = returns_the_hash
# assumes that the structure is correct
expect(hsh[:foo]).to eq("bar")
expect(hsh[:options][:zab]).to eq("xuq")
end

“隐式”测试

优点:最简洁;易于维护

缺点:做假设;结合结构/内容测试

it "should be well-formed" do
hsh = returns_the_hash
# also assumes that the structure is correct; doesn't verify it outright
expect(hsh[:foo]).to eq("bar")
expect(hsh[:options][:zab]).to eq("xuq")
end

问题

我认为,从覆盖范围的角度来看,这两种策略实际上是等同的。

在 rspec 中是否有一个约定(或者更好的是,提供的机制)来测试像这样的结构和/或内容的复杂返回值?我是否应该担心将这两个概念(结构和数据)结合起来并进行“隐式”测试,或者这种形式很糟糕,我应该像“显式”示例中那样将两者分开?

或者,我是否一开始就完全错误地解决了这个问题并违背了 Ruby/Rspec 自以为是的“方式”?

最佳答案

这取决于returns_the_hash的意图

如果它改变了,突然又回来了

{
:lorem => "ipsum",
:foo => "bar",
:baz => "qux",
:options => {
:oof => "rab",
:zab => "xuq",
},
}

这是它返回 lorem/ipsum 的错误还是没问题?

如果这表明存在错误,那么您的显式隐式 测试将无法捕捉到它,而精确 测试会捕捉到它。

如果这种情况不是错误,那么您可以更灵活地决定其他元素对您的重要性以及测试需要更少维护是否有意义。

这取决于数据的使用方式。例如,如果哈希中的所有数据最终都显示给用户,那么您的测试应该对实际返回的数据更加严格(精确 测试。)

关于ruby - 如何构造rspec数据测试?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21648728/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com