在这种情况下有多少个测试用例？

Question

我有一个方法可以执行许多操作，因此意味着会产生许多副作用。 例如，说一次对REST API的调用将返回设置了许多字段的JSON对象。 在这种情况下，如果我们要检查每个单独的字段，我们应该有一个包含多个assertEquals的单一测试方法，还是每个字段验证包含一个assertEquals的单一测试方法。

同样，一种方法可能会有很多其他副作用，例如，保存到数据库，发送电子邮件等。在这种情况下，我应该针对每种副作用使用一种单元测试方法吗？

另外，如果每个SUT方法有多个测试输入，那么这会影响创建多少个测试方法的决定吗？

而且，可能与故事有关，这意味着故事是这样说的，在这种情况下，该子功能属于故事，它们是否应该属于同一测试方法？ 因为如果需求发生变化，那么也需要改变所有影响方方面面的测试方法。 那可以管理吗？

Answer 1

在这种情况下，如果我们要检查每个单独的字段，我们应该有一个包含多个assertEquals的单一测试方法，还是每个字段验证包含一个assertEquals的单一测试方法。

担心测试用例中断言的数量就像担心函数中有多少行。 这是复杂度的一阶近似，但并不是您真正应该关注的。

您应该关心的是该测试的维护难度和诊断性能。 如果测试失败，您能否找出原因？ 这很大程度上取决于您的assertEquals对大型数据结构的性能如何。

json = call_rest();
want = { ...whatever you expect... };
assertEquals( json.from_json(), want );

如果那只是告诉您它们不相等，那不是很有用。 然后，您必须手动进入并查看json和want 。 如果它转储了两个数据结构，那也就不是很有用，您必须逐一寻找差异。

但是，如果它表示两个数据结构的有用区别，那将是有用的。 例如，Perl的Test2将产生这样的诊断信息。

use Test2::Bundle::Extended;

is { foo => 23, bar => 42, baz => 99 },
   { foo => 22, bar => 42, zip => 99 };

done_testing;

# +-------+------------------+---------+------------------+
# | PATH  | GOT              | OP      | CHECK            |
# +-------+------------------+---------+------------------+
# | {foo} | 23               | eq      | 22               |
# | {zip} | <DOES NOT EXIST> |         | 99               |
# | {baz} | 99               | !exists | <DOES NOT EXIST> |
# +-------+------------------+---------+------------------+

---

然后是维护问题，这又assertEquals您的assertEquals有多好。 单个assertEquals易于阅读和维护。

json = call_rest();
want = { ...whatever you expect... };
assertEquals( json.from_json(), want );

有很少的代码，并且want是什么预期非常明确。

虽然倍数非常罗word。

json = call_rest();
have = json.from_json();
assertEquals( have['thiskey'], 23 );
assertEquals( have['thatkey'], 42 );
assertEquals( have['foo'], 99 );
...and so on...

可能很难知道哪个断言失败，您必须通过行号或（如果测试套件支持）行号来手动命名每个断言，这需要更多的工作，更多的维护和更多的出错。

OTOH个人assertEquals允许更大的灵活性。 例如，如果您只想检查某些字段怎么办？ 如果范围内有可接受的值怎么办？

# bar just has to contain a number
assert( have['bar'].is_number );

但是某些测试套件通过单个断言来支持这一点。

want = {
    thiskey: 23,
    thatkey: 42,
    foo:     99,
    bar:     is_number
}

assertEquals( json.from_json, want );

is_number是一个特殊的对象，它告诉断言这不是正常的质量检查，而只是检查该值是否为数字。 如果您的测试套件支持这种样式，则通常优于编写一堆断言。 声明式方法意味着更少的代码编写，读取和维护。

答案是：这取决于您的测试工具有多好！