我们应该多久写一次单元测试？

Question

最近我的导师在工作中向我介绍了测试驱动的开发方法，他鼓励我写一个单元测试，“它有意义”。我理解为回归测试和refractoring提供整个单元测试套件的一些好处，但我确实想知道我们应该多长时间以及如何编写单元测试。

我的导师/开发负责人要求我为一个已经由现有测试类测试的方法编写一个新编写的控制流的单元测试用例，我认为这是一种过度杀伤力。您多久编写一次单元测试，以及您认为单元测试的详细程度如何？谢谢！

Answer 1

从技术上讲，如果你遵循严格的测试驱动开发......你应该在规定应用程序的任何部分之后编写单元测试。你应该去：

用户要求 - ＆gt;功能设计 - ＆gt;单元测试 - ＆gt;代码

记得，在TDD中的代码之前进行测试。

Answer 2

每当您编写任何代码时，都应编写单元测试。而且，正如其他人所指出的那样，在TDD中你编写之前的编写代码。

如果您认为它有点矫枉过正，请问自己“如果我不测试此代码，我怎么知道它有用？”

Answer 3

  

我的导师/开发负责人要我为新编写的控制流编写一个新的单元测试用例

除非需要通过失败的测试，否则该控制流是如何编写的？通过definition of TDD，除非首先存在需要编写代码的失败测试，​​否则不会出现生产代码。所以你必须使用一些测试最后的技术编写代码而不是TDD。

我建议您阅读文章The Art of Agile Development: Test-Driven Development。您可以使用this tutorial练习TDD。

我认为你的导师使用“只要它有意义”这个短语可能是有害的，特别是对于刚接触TDD的人，因为在经过多年的经验之后，人们不可能做出正确的决定。一个已达到Ri-level。有一次Kent Beck decided to not write a test时，Ron Jeffries对此进行了适当评论：“我相信你和其他三个人做出了很好的短期决策。”

你应该先写一个测试。任何可能破坏的东西都需要进行测试。由于某人更改代码，只有永远不会破坏的东西不需要测试。例如，声明性代码很少会破坏：网页上的静态HTML布局代码通常不值得自动测试（您必须手动测试它以查看它是否正确），但任何动态代码都值得测试。

Answer 4

单元测试应该让您自信，您编写的代码可以满足您的需求。因此，您应该编写尽可能多的测试来为您提供这种信心。

Answer 5

编写测试，更重要的是可测试代码是一项独立技能，就像学习编写每种新语言是一项独立技能一样。

阅读Miško Hevery的博客，阅读一些书籍（我喜欢Lasse Koskela的Test Driven），使用一些代码覆盖工具，如Clover，然后编写一些测试。

在编写测试时，您的测试技能将得到提高，您将了解编写可测试代码所涉及的内容。然后，您将能够了解您的特定项目所需的代码覆盖级别。

Answer 6

我也成为最近转换为TDD，我发现它非常有用。这个想法是这样的，只要你有一个规范，你就开始编写单元测试。一旦编写了测试，您的大部分代码都可以来自这些测试。你的测试中剩下的是你的断言的基础，然后你有一个非常好的可重复模式 - 写测试，实现代码，通过断言确认，继续。好东西！

Answer 7

正如贾斯汀所说，你应该在编写代码之前编写单元测试。

虽然这可能是最好的事情，但有时候会有些过分。根据项目的不同，我有时会为我找到（并解决）的每个错误编写一个单元测试。

当然，我可能会错过其中一些，但我的单元测试随着时间的推移变得越来越有效，我很确定我永远不会错过纠正的错误。

Answer 8

单元测试将：

• 让您有信心进行重构更改，同时知道您没有破坏任何其他内容。
• 充当代码的一种“活文档”，允许其他人准确了解代码在各种情况下的行为。
• 按照@Justin所述遵循严格的TDD时，在开始编写代码之前通过所有单元测试将告诉您何时“完成”编码。根据我的经验，这也会导致大大简化和易于理解（更清晰）的代码。

正如您的导师所提到的，您应该只编写有意义的单元测试。我使用的经验法则是我尝试为执行业务逻辑的代码片段编写单元测试。我通常不会为只有getter和setter的bean类编写单元测试。

随着时间的推移，单元测试通常会变得更有价值，因为它们会被扩展和增强，以便在初始交付后处理错误修复和其他代码增强。

Answer 9

在进行测试驱动开发时，单元测试有一个基本的问题，即单元测试描述功能。如果测试没有定义例如null输入如何表现，那么你无法期望它能够工作。

Answer 10

如果您现有的测试套件不足，您应该始终编写测试。最好的迹象，你的测试是不够的是错误。所以一个好的做法是为你遇到的每个bug写一个单元测试。通过测试驱动开发，您应该从一些测试开始，定义类的功能。 test-coverage-tools为您提供了一些提示，哪些部分可能需要更多测试。

Answer 11

这个问题的正确/彻底的答案必须很长，因为这是每个测试过程的关键问题，但我会回答以下简单的（？）规则：

1. 如果某个用例是重要，请为其编写单独的测试，以便其他人（或您将来）通过阅读或未通过测试来发现该案例。

   < / LI>

2. 如果您想知道超过5秒，如果某事重要足以进行测试，那么假设它是： - ）

3. 如果有任何机会测试此案例是非常困难/昂贵的，请向您的经理/技术负责人抱怨并跳过编写测试。

Answer 12

Personaly我使用单元测试，当我有大量数据时，我不想复制/粘贴很多System.out.println，并一对一地检查它们。 使用单元测试，您将丢失1小时来编写它们，并节省大量测试。对于琐碎的事情，我宁愿使用println tecnic，也不要检查调试变量。