有谁知道在哪里可以找到单元测试指南和建议?我想要解决以下类型的主题(例如):
我不应该问我应该做什么?
在线资源最好。
答案 0 :(得分:21)
我建议在TDD上预订Kent Beck's。
此外,您需要访问Martin Fowler's网站。他也有很多关于测试的好信息。
我们在TDD方面非常重要,所以我将以此为基础回答这些问题。
测试应该与应用程序逻辑在同一个项目中吗?
通常我们将测试保持在同一个解决方案中,但是我们将测试分解为单独的DLL /项目,这些DLL /项目镜像他们正在测试的DLL /项目,但是维护名称空间并且测试位于子命名空间中。示例:Common / Common.Tests
我是否应该有测试类来镜像我的逻辑类,或者我应该只有我认为需要的测试类?
是的,您应该在创建任何类之前创建测试,并且根据定义,您应该仅隔离测试单个单元。因此,您应该为解决方案中的每个类设置一个测试类。
我应该如何命名我的测试类,方法和项目(如果他们进入不同的项目)
我想强调行为是正在测试的,所以我通常在SUT之后命名测试类。例如,如果我有一个User类,我会像这样命名测试类:
public class UserBehavior
应该命名方法来描述您期望的行为。
public void ShouldBeAbleToSetUserFirstName()
项目可以根据需要进行命名,但通常您希望它正在测试哪个项目相当明显。请参阅有关项目组织的先前答案。
应该测试私有,受保护和内部方法,还是只测试可公开访问的方法?
同样,您希望测试断言预期的行为,就像您是被测对象的第三方使用者一样。如果您测试内部实现细节,那么您的测试将是脆弱的。您希望测试为您提供重构的自由,而不必担心破坏现有功能。如果您的测试了解实施细节,那么如果这些细节发生变化,您将不得不更改测试。
单元和集成测试应该分开吗?
是的,单元测试需要与验收和集成测试分开。关注点的分离也适用于测试。
是否有充分理由不进行100%的测试覆盖?
我不会挂掉100%的代码覆盖率。 100%的代码覆盖率往往意味着测试中的某种程度的质量,但这是一个神话。你可以进行可怕的测试,但仍能获得100%的覆盖率。我宁愿依靠良好的Test First心态。如果您在编写一行代码之前总是编写测试,那么您将确保100%的覆盖率,因此它变得没有实际意义。
一般情况下,如果您专注于描述课程的完整行为范围,那么您将无需担心。如果你将代码覆盖率作为度量标准,那么懒惰的程序员只会做足够的事情来满足那个标记,你仍然会有糟糕的测试。相反,在很大程度上依赖同行评审,同时也会审查测试。
答案 1 :(得分:3)
这是一个很好的问题。我们有机地发展了自己,我怀疑最好的方法就是这样。那里有一点“它取决于......”。
我们在同一个项目中,在名为“UnitTes”的子命名空间中放置测试
我们的测试类镜像逻辑类,以简化跟踪测试与测试内容的关系
类的命名类似于他们正在测试的逻辑类,方法是根据他们正在测试的场景命名的。
我们只为公共和内部方法编写测试(测试在同一个项目中),目标是覆盖95%的课程。
我不想区分“单位”和“整合”。要花很多时间来弄清楚哪个是哪个......包包那个!测试是一项测试。
100%难以一直难以实现。我们的目标是95%。获得最终5%所花费的时间以及它实际捕获的内容的回报也在递减。
这就是我们以及适合环境和节奏的因素。你的milage可能会有所不同。想想你的环境和所涉及的个性。
我期待看到其他人对此问题的看法!
答案 2 :(得分:3)
Josh的回答是正确的 - 只有一点澄清:
我将单元测试与集成和验收测试分开的原因是速度。我使用TDD。我需要接近关于我刚创建/修改的代码行的即时反馈。如果我正在运行完整的集成和/或验收测试套件,那么我就无法做到这一点 - 这些测试可以触及真正的磁盘,真正的网络以及真正缓慢且不可预测的外部系统。
不要穿过横梁。如果你这样做会发生坏事。
答案 3 :(得分:1)
答案 4 :(得分:1)
按顺序:
答案 5 :(得分:1)
关于你的上一个问题,根据我的经验,不坚持100%测试覆盖率的“好”理由是,需要花费不成比例的努力来获得最后几个百分点,特别是在更大的代码库中。因此,一旦达到收益递减点,就决定是否值得花时间。
答案 6 :(得分:1)
测试应该与应用程序逻辑在同一个项目中吗?
这取决于。无论如何都有权衡。
将其保留在一个项目中需要额外的带宽来分配您的项目,额外的构建时间并增加安装空间,并且更容易犯下依赖于测试代码的生产逻辑的错误。
另一方面,保持单独的项目可能会使编写涉及私有方法/类(取决于编程语言)的测试变得更加困难,并导致轻微的管理麻烦,例如建立新的开发环境(例如,当一个新的开发人员更加努力地加入该项目。
这些不同成本的重要程度因项目而异,因此没有普遍的答案。
我应该有测试类来镜像我的逻辑类,还是应该只有我认为需要的测试类?
没有
您应该拥有允许考虑周全的测试代码的测试类(即最小重复,明确意图等)。
直接镜像测试类中的逻辑类的明显优势在于,它可以轻松找到与特定代码段相对应的测试。在不限制测试代码的灵活性的情况下,还有其他方法可以解决此问题。测试模块和类的简单命名约定通常就足够了。
我应该如何命名我的测试类,方法和项目(如果他们进入不同的项目)
您应该将它们命名为:
应该测试私有,受保护和内部方法,还是只能公开访问?
通常应该测试非公开方法。这取决于您是否从仅测试公共界面获得足够的信心,或者您真正想要测试的单元是否可以公开访问。
单元和集成测试应该分开吗?
这取决于您选择的测试框架。做任何最适合您的测试框架的方法,并使其成为:
是否有充分的理由不进行100%的测试覆盖?
是的,有充分的理由。严格来说,“100%测试覆盖率”意味着您的代码中的每种可能情况都会得到锻炼和测试。这几乎对任何项目来说都是不切实际的。
如果您只是采用“100%测试覆盖率”来表示测试套件在某些时候执行了每行源代码,那么这是一个很好的目标,但有时在尴尬的地方只有几行自动化测试很难达到。如果定期手动验证该功能的成本低于通过扭曲达到最后五行的成本,那么这是不能实现100%线路覆盖的一个很好的理由。
而不是一个简单的规则,你应该有100%的线覆盖率,鼓励你的开发人员发现你的测试中的任何缺口,并找到解决这些差距的方法,无论是行数还是行数“覆盖“改善。换句话说,如果你测量覆盖的线条,那么你将改善你的线覆盖 - 但你真正想要的是提高质量。因此,不要忘记线条覆盖率只是质量的粗略近似值。