单元测试指南

有谁知道在哪里可以找到单元测试指南和建议？我想要一些解决以下类型主题的东西(例如):

测试应该与应用程序逻辑在同一个项目中吗？

我应该有测试类来镜像我的逻辑类,还是应该只有我认为需要的测试类？

我应该如何命名我的测试类,方法和项目(如果他们进入不同的项目)

是应该测试私有,受保护和内部方法,还是只测试可公开访问的方法？

单元和集成测试应该分开吗？

是否有充分的理由不进行100%的测试覆盖？

我不应该问我应该怎么做？

在线资源最好.

我会推荐Kent Beck关于TDD 的书.

此外,你需要去Martin Fowler的网站.他也有很多关于测试的好信息.

我们在TDD上非常重要,所以我将从这个角度回答这些问题.

测试应该与应用程序逻辑在同一个项目中吗？

通常我们将测试保存在同一个解决方案中,但我们将测试分解为单独的DLL /项目,这些DLL /项目镜像他们正在测试的DLL /项目,但是维护命名空间,测试位于子命名空间中.示例:Common/Common.Tests

我应该有测试类来镜像我的逻辑类,还是应该只有我认为需要的测试类？

是的,应该在创建任何类之前创建测试,并且根据定义,您应该仅隔离测试单个单元.因此,您应该为解决方案中的每个类设置一个测试类.

我应该如何命名我的测试类,方法和项目(如果他们进入不同的项目)

我想强调行为是正在测试的,所以我通常在SUT之后命名测试类.例如,如果我有一个User类,我会将测试类命名为:

public class UserBehavior

应该命名方法来描述您期望的行为.

public void ShouldBeAbleToSetUserFirstName()

可以根据需要命名项目,但通常您希望项目正在测试哪个项目.请参阅有关项目组织的先前答案

是应该测试私有,受保护和内部方法,还是只测试可公开访问的方法？

您再次希望测试断言预期的行为,就像您是被测对象的第三方使用者一样.如果您测试内部实现细节,那么您的测试将是脆弱的.您希望测试为您提供重构的自由,而不必担心破坏现有功能.如果您的测试了解实施细节,那么如果这些细节发生变化,您将不得不更改测试.

单元和集成测试应该分开吗？

是的,单元测试需要与验收和集成测试隔离开来.关注点的分离也适用于测试.

是否有充分的理由不进行100%的测试覆盖？

我不会挂掉100%的代码覆盖率.100%的代码覆盖率往往意味着测试中的某种程度的质量,但这是一个神话.你可以进行可怕的测试,但仍能获得100%的覆盖率.我宁愿依靠良好的Test First心态.如果您在编写一行代码之前总是编写测试,那么您将确保100%的覆盖率,因此它变得没有实际意义.

一般来说,如果你专注于描述课程的完整行为范围,那么你将无需担心.如果你将代码覆盖率作为度量标准,那么懒惰的程序员只会做足够的事情来满足那个标记,你仍然会有糟糕的测试.相反,在很大程度上依赖同行评审,同时评估测试.