编写单元测试时要测试什么？

Question

我想开始对我们的应用程序进行单元测试,因为我相信这是与测试建立良好关系的第一步,并允许我分支到其他形式的测试,最有趣的是带有Cucumber的BDD.

我们目前使用Codesmith生成所有Base类,它们完全基于数据库中的表.我很好奇使用这些Base类生成测试用例的好处？这是不好的测试实践吗？

这让我想到了我的帖子的终极问题.使用单元测试时我们测试什么？

我们是否测试了我们想知道的例子？还是我们测试我们不想要的例子？

他们可以采用多种失败方式和多种成功方式,我们如何知道何时停止？

以Summing函数为例.给它1,2并且在唯一的单元测试中期望3 ..我们怎么知道5,6不回来35？

问题回顾

• 生成单元测试(好/坏)
• 我们测试什么/多少？

Answer 1

从您的要求开始,编写测试预期行为的测试.从那时起,您测试的其他场景可以由您的日程表驱动,也可能由您识别特别高风险的非成功场景驱动.

您可以考虑编写非成功测试,仅用于响应您(或您的用户)发现的缺陷(想法是您在实际修复缺陷之前编写测试缺陷修复的测试,以便如果缺陷导致测试失败在未来的开发中重新引入您的代码中).

Answer 2

单元测试的目的是让你有信心(但只有在特殊情况下才能确定),公共方法的实际行为与预期的行为相匹配.因此,如果你有一个班级Adder

class Adder { public int Add(int x, int y) { return x + y; } }

和相应的单元测试

[Test]
public void Add_returns_that_one_plus_two_is_three() {
    Adder a = new Adder();
    int result = a.Add(1, 2);
    Assert.AreEqual(3, result);
}

那么这给了你一些(但不是100%)的信心,即测试中的方法表现得恰当.它还为您提供了一些防止在重构时破坏代码的防御.

使用单元测试时我们测试什么？

公共方法对预期(或指定)行为的实际行为.

我们是否测试了我们想知道的例子？

是的,获得对方法正确性的信心的一种方法是使用已知预期输出的一些输入,对输入执行公共方法并将实际输出与预期输出进行比较.