单元测试 – 单元测试：什么测试/什么不测试？

自从前几天我开始对C#和VS2010中的单元测试和TDD感兴趣.我已经阅读了博客文章,观看YouTube教程,还有更多的内容,解释了为什么TDD和单元测试对您的代码非常好,以及如何做到这一点.

但是我发现的最大的问题是,我不知道要检查我的测试和什么不检查.

我明白我应该检查所有的逻辑操作,引用和依赖关系的问题,但是例如,我应该创建一个单元格测试,这个字符串格式被忽略为用户输入？还是只是浪费我的时间,而我可以在实际的代码中检查它？

有没有指导澄清这个问题？

在TDD中,每行代码必须由在代码之前编写的失败的测试用例来证明.

这意味着您无法在没有测试用例的情况下开发任何代码.如果您有一行代码(条件,分支,赋值,表达式,常量等),可以修改或删除,而不会导致任何测试失败,这意味着这一行代码是无用的,应该被删除(或者你有一个缺失的测试来支持它的存在).

这有点极端,但这正是TDD的工作原理.这就是说,如果你有一段代码,你想知道是否应该测试,你没有正确做TDD.但是,如果您有一个字符串格式化例程或可变递增或任何一小段代码,则必须有一个支持它的测试用例.

UPDATE(由Ed.提出的用例)：

Like for example,adding an object to a list and creating a test to see if it is really inside or there is a duplicate when the list shouldn’t allow them.

这是一个反例,你会惊讶于发现复制粘贴错误以及它们是多么的普遍：

private Set<String> inclusions = new HashSet<String>();
private Set<String> exclusions = new HashSet<String>();

public void include(String item) {
    inclusions.add(item);
}

public void exclude(String item) {
    inclusions.add(item);
}

另一方面,单独测试include()和exclude()方法是一种过分的,因为它们本身并不表示任何用例.但是,它们可能是一些业务用例的一部分,您应该进行测试.

显然你不应该测试x = 7中的x是否真的是7.还测试生成的getter / setter是一个过度的杀伤力.但这是最容易断断续续的代码.由于复制和粘贴错误或拼写错误(特别是动态语言),所以常常.

也可以看看：

> Mutation testing