【发布时间】：2008-10-17 11:09:02
【问题描述】：
我们即将开始项目的一个新部分，似乎对单元测试没有太多兴趣（而且感觉他们没有经历过 TDD）。我相信它几乎是必不可少的，它使维护变得更加容易。 那么你有什么看法呢？
谢谢
顺便说一句：这是一个与语言无关的问题，但是新项目是用 Java 编写的。
【问题讨论】：
标签： unit-testing testing architecture tdd
【发布时间】：2008-10-17 11:09:02
【问题描述】：
在我们的项目中绝对使用单元测试。每个不是无脑 getter 和 setter 的类都经过单元测试。对您的代码进行功能测试使您可以随意重构，而不必担心一次会破坏 50 种不同的东西。
单元测试的另一个被低估的方面是它将算法中被忽视的方面暴露出来。我只花了两天时间使用正交数组编写和重写单元测试，因为每次我想出一个测试用例列表时，我都会发现技术主管忽略的问题的另一个方面。
【讨论】：
我发现单元测试不仅仅是一件有用的事情，它也是开发人员的责任。如果你发布的代码没有通过一组有效和全面的单元测试，你很可能会延迟你的项目，或者导致其他人的包、类等出现问题。
此外，您应该与您的客户（即使是您自己的公司）保持密切联系，并尝试并鼓励他们进行全面的验收测试。这符合他们的最大利益（尽管我发现一些公司反对这个想法，因为执行测试所需的时间很短，尽管如果产品不能完全执行它会节省大量时间他们想要什么）。
编辑
所以，是的，我想我想说的是：是的，我确实认为Test Driven Development 是要走的路。我当然没有提到的另一件事是测试有助于记录代码这一事实。您将知道这些方法应该做什么，并且当您在以后的任何阶段进行更改时，您将确保它们仍然可以执行。
【讨论】：
-
TDD 是唯一的飞行方式，呃，我是说代码。过去六个月在专业发展方面一直在做 TDD。在此之前只是单元测试。学习需要时间，但我现在永远不会没有它。
-
我完全同意。我最初是一名传统的瀑布式开发人员，但没有进行单元测试。我现在更倾向于敏捷、测试驱动的开发。它有什么不同。每一个测试都让你感觉离完成更近了:D
是的。我们使用 TDD 已经有一段时间了。不知何故，我们发现了 TDD，我们喜欢这种增量方法，以实现更好的代码质量。尽管有最初的拒绝曲线，您认为在许多方面编写代码时进行一致和渐进的单元测试会减慢开发速度。由于正在逐步构建回归测试框架，因此很难编写重大更改。如果做得好，代码会更加健壮，并且对代码和整个项目的信心都会受到积极影响。
如今编写单元测试不仅仅适合精英。这应该是每个开发人员的责任。越晚在代码中发现错误，修复的成本就越高，也就越难找到。这很容易成为维护的噩梦。强烈支持单元测试可以大大降低这种风险。
将单元测试和 TDD 的强大功能与配置良好的持续集成系统相结合，可以在项目的早期阶段快速发现问题。每天构建是避免未来和几乎可以肯定的麻烦的必要条件。
【讨论】：
单元测试是有代价的。首先，您必须编写并验证所有额外的代码。然后你可能不得不在项目团队中推动昂贵的文化变革来接受单元测试。
这个价格对于您的特定项目来说可能是值得的。该决定不应基于教条或轶事，而应基于对成本和收益的仔细分析。
【讨论】：
-
我不同意你的观点，因为我认为测试有助于降低长期成本，因为它有助于编写更好的代码。这不是教条问题，而是质量问题
-
我也怀疑它会降低成本，但这并不意味着它不值得分析。
-
有些系统不适合采用单元测试。例如，系统不采用强大的分层方法并导致业务和表示逻辑的混合。我相信已经有一个相关的堆栈溢出问题。
-
当你说“长期”时，一个只会使用几个月的项目呢？或者一旦实施就永远不可能改变？我做了很多这些，这就是为什么我说你必须先做一个成本/收益分析。
严格来说不是 TDD，但我会对我编写的每一段代码进行单元测试。我对它的看法与我对源代码控制和重构的看法相同；它们是你做来编写高质量代码的东西。我不会想到 not 单元测试。
【讨论】：
-
我在同一个阵营。我进行了单元测试（通常使用与 TDD 人员相同的框架——我的选择是 NUnit），但通常不会“全力以赴”使用整个 TDD 口头禅。
我无法想象现在在没有自动化测试的情况下进行项目（单元/集成等...）
其实我经常说
“如果这坏了，那不是我的错”
在处理没有测试的人们的代码时。
【讨论】：
在一段代码按照客户真正想要的方式运行后，我们会进行单元测试。一开始我们做单元测试的速度太快了，当客户改变主意时（相信我），你经常不得不删除代码以及单元测试。这太耗时且成本高昂。我支持单元测试，但TDD 对我们来说并不划算。
【讨论】：
我发现 TDD 确实很有用，但一些开发人员直到编写一些新代码破坏了旧测试时才看到它的价值。
【讨论】：
当您在论坛上提问时，很多人会说单元测试是“强制性的”，但实际上单元测试的考虑正如调查结果所示。有关更多参考资料/材料，请参阅http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2。
【讨论】：
我希望我可以在我的项目中更多地使用单元测试，并且我希望我的同事至少在编写一些测试。 :)
在我的例子中，启用单元测试和使用 TDD 实践需要付出相当高的代价。它主要依赖于工具，这些工具对于我们正在使用的框架来说是相当糟糕的。如果只需单击整个项目（或单击两次，以防我们目前需要特定测试）就可以执行单元测试，那会容易得多。我们现在使用的工具并没有真正得到回报——有时手动发现错误比运行测试更容易。
使用 Java，有更好的工具，所以您现在真的应该开始编写测试了！调试很糟糕，测试很糟糕，真的。
【讨论】：
-
您使用的框架是什么？现在奇怪的现有框架不允许简单的单元测试实现。
不幸的是，不是每次。我们最关键的任务系统充满了单元测试，以确保他们做他们应该做的事情，并且不管开发人员如何都继续这样做。 对于其他系统，大多数时候开发时间太短，无法将其花在编写测试上。 （但最终赢得的时间是在调试上花费了两次。）
【讨论】：
是的。除非客户在我头上拿着枪，以便在一天结束前将功能推出门外。
【讨论】：
单元测试（我在这里考虑 JUnit）和 TDD 是当您使用新代码开始一个新项目时要走的路（您将需要更多类似 CI）。
但是，当您的新项目要修改一个旧代码库时，该代码库中的每个类都包含 5KLOC 的紧耦合类，那么单元测试很困难，并且大多数时候项目时间线不允许重构（或重写） ）。如果这是您即将开始的那种项目，我建议您阅读“使用遗留代码”以了解旧代码的测试策略。
【讨论】：
在所有新开发中，我们现在都进行 TDD。对于遗留维护，我们创建失败的单元测试以暴露报告的缺陷并逐步建立一个库。
这是一种文化冲击，但当您意识到您将更多时间用于新开发而减少寻找错误的时间时，它确实会带来回报。
【讨论】：
是的，只要我能。我必须支持我编写的代码，而且我知道在开发过程中花费的少量额外时间使我免于在发布后花费大量额外时间。
【讨论】：
我有兴趣这样做，但不知道如何开始我最终参与的大型项目...自 1996 年以来就没有参与过真正全新的项目！
【讨论】：
-
我认为尝试将其引入已经存在的项目中非常困难。您通常可以期望的最好的结果是随着时间的推移构建一套单元测试来保护您继续前进，但您可能无法获得测试优先设计所提供的覆盖率。
如果值得写，那就值得测试。
【讨论】：