比可测试代码大2-3倍的测试

您可能测试了错误的东西—您不应该对代码中的每个方法都进行不同的测试。

另一个原因是大型测试缺乏隔离(也称为模拟),如果您需要初始化需要大量代码的困难对象,请尝试改用伪代码/模拟。

单元测试代码应该遵循与生产代码相同的最佳实践。如果你有那么多的单元测试代码,那就有一种 违反干燥原则

重构单元测试以使用 Test Utility Methods

太多的测试代码可能意味着被测试的实际代码不是为可测试性而设计的。有一个伟大的 guide on testability 来自谷歌的开发者试图解决这个问题。

糟糕的代码设计意味着大量的测试代码只有一个原因:使实际代码可测试。有了一个好的设计,测试可以更加集中在重要的方面。

好,

这是一个权衡的场景,更多的测试可以确保稳定性。通过稳定性,它不仅意味着被测试的代码更加无错误和万无一失,还保证了程序在将来的任何情况下都不会崩溃。无论您将参数传递给一个方法多么疯狂,代码块都会正确返回(当然,在需要时会有适当的错误消息)。

更重要的是,您甚至可以在了解被测方法的内部操作之前编写单元测试用例。这就像一个黑匣子场景,在这个场景中,您将首先完成测试用例的编写,然后开始编码。最大的优点是,通过并行运行测试用例,开发工作将在更少的迭代中变得无错误。

测试代码的大小根本不重要。重要的是单元测试的全面性和覆盖范围。无论它只是测试namesake还是它是一个处理所有可能情况的严肃测试用例。

测试应该是找到正确的平衡,这取决于许多不同的因素,例如:

• 商业目的(想想“起搏器控制器”和“电影库存管理器”)
• 开发人员的技能
• 员工流动率(开发人员池中增加人员的频率)
• 复杂性(软件的复杂性,与上述“业务目的”相关)

我通常只为“public API”编写测试,因此只隐式地测试用于传递公共功能的任何程序集内部类。但随着你对可靠性和再现性要求的提高,你也应该增加额外的测试。

这个问题很有道理也很好。我在需要的时候遵循简单的原则。

1. 为我们知道的问题设置类别(关键、高、低)
3. 设置优先级
4. 然后解决问题

这一点经常是正确的。找出这是好事还是坏事的关键是找出测试规模较大的原因。

有时它们更大仅仅是因为有很多测试用例要覆盖,或者规范很复杂,但是实现规范的代码没有那么长。

• 否则,我认为您可以重构代码,以便将重复的代码移到不同的方法中
• checkstyle (或其他工具)检查代码重复

关于这些单元测试有趣的一点是,即使在我编写它们之后,我仍然对这些类是否工作感到不安,这导致我使用数据库、web服务或身份验证服务编写集成测试。只有在建立了自动化集成测试之后,我才觉得可以继续前进。

集成测试通常比它们各自的单元测试要短得多,并为我和团队中的其他开发人员证明系统的这部分工作做了更多的工作。

-然而-

归根结底,我对包含自动化集成测试一直感觉很好,但几乎总是觉得这些“集成”类的单元测试是一项没有多少回报的工作。

大2-3倍的测试是不正常的。

在测试中使用助手类/方法。

限制测试范围。

有效使用测试夹具。

有效地使用单元测试框架。

你就不会再做这样的测试了。

是的,很可能测试的loc比您正在测试的实际代码要多,但是考虑到您在调试代码时节省的时间,这是完全值得的。

不必每次进行更改时都手工测试整个应用程序/库,您可以依赖您的testsuite,如果它失败,您可以获得比“它不工作”更准确的关于它在哪里损坏的信息。

关于避免测试:如果你不测试代码的某些部分,你实际上破坏了测试的整个概念和目的,那么测试实际上是毫无用处的。

但是,你不会测试你没有写的东西。也就是说,假设外部库正常工作,并且生成的getter/setter方法(如果您的语言支持这些方法)也不必进行测试。我们可以很安全地假设,它在为变量赋值时不会失败。

当我编写测试或进行TDD(顺便说一句,我从对我的一个问题的回答中学到了这一点)时,指导我的一件事情是,你不必像对待实际代码那样小心测试的设计/架构。测试可能有点脏,不太理想(代码设计方面),只要他们做得对。就像所有关于设计的建议一样,要明智地运用,经验是无可替代的。

是的,这很正常。测试代码比生产代码长不是问题。

也许你的测试代码可能比现在短,也许不短,但无论如何你都不想让测试代码变得“聪明”,我认为在第一次编写测试代码之后,除非绝对必要,否则你不想把测试代码重构成普通的东西。例如,如果您对过去的bug进行了回归测试,那么除非您更改了测试中的公共接口,否则不要接触该测试代码。永远不会。如果你这样做了,你只需要从bug被修复之前拿出一些古老的实现版本,来证明新的回归测试仍然可以完成它的工作。浪费时间。如果您修改代码的唯一时间是为了使其“更易于维护”,那么您只是在创建繁忙的工作。

添加新的测试通常比用新的测试替换旧的测试要好得多,即使您最终得到的是重复的测试。你冒着犯错误的危险没有任何好处。例外情况是,如果您的测试运行的时间太长,那么您希望避免重复,但即使这样,最好还是将您的测试拆分为“核心测试”和“完整测试”,并且运行所有旧的重复测试,可能频率较低。

SQLite's test code to production code ratio