单元测试如何提高生产力？

Question

我目前正在寻找提高团队生产力的方法.我已经在很多地方读过,可以使用单元测试来提高生产率.我可以想象,现在编写单元测试在将来会有所帮助,但它在短期内也有帮助吗？因为我不明白如何编写更多代码(=更多潜在的错误)可以帮助我们满足最后期限.

Answer 1

单元测试不是每天产生更多代码行.

这是为了确保每天都有新的代码行不会导致更多错误.

当你试图评估你的"生产力"时,你需要非常小心.但是,它可能会帮助您满足最后期限,因为您将花费更少的时间来修复内容.

它不是针对"短期"的东西,因为"我们将使用单元测试,我们的下一个项目将在80%的时间内完成".

Answer 2

不是短期内,但不长期限要么,具有自动化测试可以让你及时发现问题(回归)所造成的错误bug修复,或错误的发展,速度更快; 这绝对是件好事.

这意味着当您的应用程序处于测试阶段时,每次更正错误时,您引入新错误的风险就会降低.
只要应用程序仍在开发中,这也是正确的:每次开发人员提交一个新模块时,你知道它不会破坏应用程序的其余部分(或者,至少,它不会破坏什么是由自动化测试覆盖)

并且越早检测到错误,修复就越简单且成本越低:如果错误没有时间影响其他开发人员,那么它也会更好.
如果开发人员将某些"bug" (他不知道是一个bug)视为一个功能并开始依赖它,该怎么办？当这开始被视为一个错误并被修复时会发生什么？其他代码打破了,我想:-(

好的一点是,开发自动化测试可能意味着更多的开发人员更多地了解应用程序的代码:特别是如果某些测试由其他开发人员开发/审查,而不是首先编写代码的开发人员.
不确定它是"好的实践",但如果以这种方式完成,这意味着将会有某种代码审查 - 这些肯定是有帮助的.

随着越来越多的开发人员了解代码,更多的开发人员将能够修复他们最初未开发的部分中的错误.

Answer 3

通过单元测试提高生产力

另请参阅测试驱动开发

测试驱动开发(TDD)是一种软件开发技术,它使用基于预先编写的测试用例的简短开发迭代,这些测试用例定义了所需的改进或新功能.每次迭代都会生成传递迭代测试所需的代码.最后,程序员或团队重构代码以适应变化.关键的TDD概念是在编码之前准备测试有助于快速反馈变化.请注意,测试驱动开发是一种软件设计方法,而不仅仅是一种测试方法.

Answer 4

对于单元测试，“测试”是错误的词。“定义行为”也许是一个更好的术语。

单元测试和TDD可以通过多种方式提高生产率（甚至中期）。

• 具有已知行为的代码易于调试，这是众所周知的行为。
• 用TDD方法编写的代码往往具有更清晰的“接缝”，从而可以独立验证部分代码库。这样可以更轻松地缩小问题发生的范围。
• 由于强大的测试套件和明确定义的行为，重构变得非常容易。即使设计问题影响多个单独的类，这也使解决问题的风险大大降低。
• 由于上述原因，通常更容易确定出现问题的时间，修复程序的正确位置。
• 由于TDD编写的代码往往不那么依赖单例/静态行为或全局状态，因此存在较少的全局行为。通过较少的全局行为，您可以获得较少的副作用。

以我的经验，TDD编写的代码的最大优点是定义明确。您首先要定义代码应该做什么，然后再使其执行。这与“常规”开发实践形成对比，后者通常涉及编写一堆代码，然后对其进行测试以查看其实际作用。

使用类似TDD的方法的另一个优点是，即使没有端到端解决方案，您也几乎可以立即获得工作代码。而且，添加到工作代码中以获取更多工作代码几乎总是容易得多，而不是编写一堆处于未知状态的代码，然后找出无法正常工作的代码。