我们应该多久写一次unit testing？
最近我的导师在工作中向我介绍了测试驱动的开发方法，他鼓励我写一个unit testing，“它有意义”。 我理解为回归测试和refractoring提供整个unit testing套件的一些好处，但我确实想知道我们应该多长时间以及如何编写unit testing。
我的导师/开发负责人要求我为一个已经由现有测试类测试的方法中新编写的控制流编写一个新的unit testing用例，我认为这是一种过度杀伤力。 您多久编写一次unit testing，以及您认为unit testing的详细程度如何？ 谢谢！
从技术上讲，如果你遵循严格的测试驱动开发……你应该在规定应用程序的任何部分之后编写unit testing。 你应该去：
用户要求 – >function设计 – >unit testing – >代码
记得， 测试在TDD中出现在Code之前 。
无论何时编写任何代码，都应该编写unit testing。 并且，正如其他人所指出的，在TDD中，您在编写代码之前编写测试。
如果您认为它有点矫枉过正，请问自己“如果我不测试此代码，我怎么知道它有效？”
我的导师/开发负责人要我为新编写的控制流编写一个新的unit testing用例
除非需要通过失败的测试，否则如何编写控制流程？ 根据TDD的定义 ，除非首先存在需要编写代码的失败测试，否则不会出现生产代码。 所以你必须使用一些测试最后的技术而不是TDD来编写代码。
我建议你阅读文章敏捷开发的艺术：测试驱动开发 。 您可以使用本教程练习TDD。
我认为你的导师使用“只要它有意义”这个短语可能是有害的，特别是对于刚接触TDD的人来说，因为在经历了多年的经验之后，人们不可能做出正确的决定。 Ri级别 。 有一次当肯特贝克决定不参加考试时 ，罗恩杰弗里斯对此进行了适当的评论：“我相信你，以及其他三个人，做出好的短期比赛决定。”
你应该先写一个测试。 任何可能破坏的东西都需要进行测试。 只有因为某人更改代码而永远不会破坏的东西不需要测试。 例如，声明性代码很少会破坏：网页上的静态HTML布局代码通常不值得自动测试（您必须手动测试它以查看它是否正确），但任何动态代码都值得测试。
unit testing应该让您自信，您编写的代码可以满足您的需求。 因此，您应该编写尽可能多的测试来为您提供这种信心。
编写测试，更重要的是可测试代码是一项独立技能，就像学习编写每种新语言是一项独立技能一样。
阅读MiškoHevery的博客，阅读一些书籍（我喜欢Lasse Koskela的测试驱动 ），使用一些代码覆盖工具，如Clover ，然后编写一些测试。
在编写测试时，您的测试技能将得到提高，您将了解编写可测试代码所涉及的内容。 然后，您将能够了解您的特定项目所需的代码覆盖级别。
我也成为最近转换为TDD，我发现它非常有帮助。 这个想法是这样的，只要你有一个规范，你就开始编写unit testing。 一旦编写了测试，大部分代码都可以来自这些测试。 你的测试中剩下的是你的断言的基础，然后你有一个非常好的可重复模式 – 写测试，实现代码，通过断言确认，继续。 好东西！
正如Justin所说，在编写代码之前，您应该编写unit testing。
虽然这可能是最好的事情，但有时候会有些过分。 根据项目的不同，我有时会为我找到（并解决）的每个bug编写一个unit testing。
当然，我可能会想念其中的一些，但我的unit testing随着时间的推移变得越来越有效，我很确定我永远不会错过纠正的错误。
unit testing将：
- 让你有信心进行重构更改，同时知道你没有破坏任何其他东西。
- 充当代码的“活文档”，允许其他人准确了解代码在各种情况下的行为方式。
- 当遵循@Justin描述的严格TDD时，通过在开始编写代码之前编写的所有unit testing将告诉您何时“完成”编码。 根据我的经验，这也导致大大简化和易于理解（更清晰）的代码。
正如您的导师所提到的，您应该只编写有意义的unit testing。 我使用的经验法则是我尝试为执行业务逻辑的代码片段编写unit testing。 我通常不会为只有getter和setter的bean类编写unit testing。
随着时间的推移，unit testing通常会变得更有价值，因为它们被扩展和增强，以处理错误修复和初始交付后进行的其他代码增强。
在进行测试驱动开发时，unit testing有一个基本的问题，即unit testing描述function 。 如果测试没有定义例如null输入的行为，那么你就不能指望它能够工作。
如果您现有的测试套件不足，您应该总是编写测试。 最好的迹象，你的测试是不够的是错误。 所以一个好的做法是为你遇到的每个bug写一个unit testing。 通过测试驱动开发，您应该从一些测试开始，定义类的function。 test-coverage-tools为您提供了一些提示，哪些部分可能需要更多测试。
这个问题的正确/彻底的答案必须很长，因为这是每个测试过程的关键问题，但我会回答以下简单的（？）规则：
-
如果某些用例很重要 ，请为其单独进行测试，以便其他人（或您将来）通过阅读或未通过测试来发现该情况。
-
如果你想知道超过5秒钟是否有足够重要的东西可以测试，那么假设它是:-)
-
如果有任何机会测试这个案例非常困难/昂贵，请向您的经理/技术负责人抱怨并跳过编写测试。
Personaly我使用unit testing，当我有大量数据时，我不想复制/粘贴很多System.out.println，并一对一地检查它们。 使用unit testing，您将丢失1小时来编写它们，并节省大量测试。 对于琐碎的事情，我宁愿使用println tecnic，或检查调试变量。