单元测试指南

我推荐 Kent Beck's

另外,你需要去 Martin Fowler's 地点他也有很多关于测试的好信息。

我们非常重视TDD,所以我将从这个角度回答问题。

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

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

是的,您的测试应该在创建任何类之前创建,根据定义,您应该只单独测试单个单元。因此,解决方案中的每个类都应该有一个测试类。

我应该如何命名我的测试类、方法和项目(如果它们在不同的项目中)

public class UserBehavior

public void ShouldBeAbleToSetUserFirstName()

项目可以按照您想要的方式命名,但通常您希望它非常明显地显示它正在测试哪个项目。请参阅前面关于项目组织的回答。

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

同样,您希望测试能够断言预期的行为,就像您是被测试对象的第三方消费者一样。如果您测试内部实现细节,那么您的测试将是脆弱的。您希望您的测试能够给您重构的自由,而不必担心破坏现有功能。如果您的测试知道实现细节,那么如果这些细节发生更改,您将不得不更改测试。

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

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

我不会挂断100%代码覆盖率的事情。100%的代码覆盖率往往意味着测试中的某种质量水平,但这是一个神话。你可以进行糟糕的测试,但仍然可以获得100%的覆盖率。相反,我会依靠一种良好的考试第一心态。如果您总是在编写一行代码之前编写测试,那么您将确保100%的覆盖率,因此它将成为一个没有实际意义的点。

一般来说,如果你专注于描述类的全部行为范围,那么你就没有什么可担心的了。如果您将代码覆盖率作为一个指标,那么懒惰的程序员只需做足够的工作就可以达到这个指标,而且您仍然会有糟糕的测试。取而代之的是严重依赖同行评议,在同行评议中也会对测试进行评议。

我们在同一个项目中,在名为“Unites”的子命名空间中进行测试

我们的测试类反映了逻辑类,以简化跟踪测试位置与测试内容的关系

我们只为公共和内部方法编写测试(测试在同一个项目中),目标是95%的类覆盖率。

我不想区分“单位”和“整合”。要花很多时间去弄清楚哪个是哪个…把那个包起来!考试就是考试。

这就是我们,也正是我们适应了环境和节奏。你的年龄可能不同。想想你所处的环境和所涉及的个性。

Josh的回答是正确的-只有一点需要澄清:

不要穿过横梁。如果你这样做,坏事就会发生。

Test Driven Development: By Example 和 Test-Driven Development: A Practical Guide 一个主题的问题太多了

• 不,通常最好将它们包含在单独的项目中;除非您希望能够在运行时运行诊断。
• 理想的情况是100%的代码覆盖率,这意味着每个类中每个例程中的每一行代码。
• 每件事
• 我会说是的,因为如果单元测试失败,则不需要运行集成测试。

视情况而定。这两种方式都有权衡。

将其保存在一个项目中需要额外的带宽来分发您的项目、额外的构建时间和增加安装占用空间,并且更容易犯下生产逻辑依赖于测试代码的错误。

这些不同的成本在多大程度上因项目而异,因此没有统一的答案。

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

您应该拥有允许良好分解的测试代码的测试类(即,最小的重复、清晰的意图等)。

直接在测试类中镜像逻辑类的明显优势在于,它可以轻松找到与特定代码段对应的测试。还有其他方法可以在不限制测试代码灵活性的情况下解决此问题。测试模块和类的简单命名约定通常就足够了。

您应该为它们命名,以便:

• 每个测试类别和测试方法都有明确的目的,以及
• 因此,寻找特定测试(或关于特定单元的测试)的人可以很容易地找到它。

通常,应该测试非公共方法。这取决于您是否从测试公共接口中获得足够的信心,或者您真正想要测试的单元是否不可公开访问。

这取决于您选择的测试框架。选择最适合您的测试框架的方法,并确保:

• 与一段代码相关的单元测试和集成测试都很容易找到,
• 只运行集成测试很容易,
• 运行所有测试都很容易。

如果您只是简单地将100%的测试覆盖率视为测试套件在某个时刻执行每一行源代码,那么这是一个很好的目标,但有时在一些尴尬的地方只有几行代码难以通过自动化测试实现。如果定期手动验证功能的成本低于通过扭曲达到最后五行的成本,那么这就是不具有100%行覆盖率的一个很好的理由。

任何