我们即将开始项目的一个新部分，似乎对单元测试没有太多兴趣（而且感觉他们没有经历过 TDD）。我相信它几乎是必不可少的，它使维护变得更加容易。那么你的观点是什么？
谢谢
顺便说一句：这是一个与语言无关的问题，但是新项目是用 Java 编写的。
Roundcrisis
问问题
1114 次
17 回答
8
我发现单元测试不仅仅是一件有用的事情，它也是开发人员的责任。如果您发布的代码尚未编写为通过一组有效且全面的单元测试，那么您很可能会延迟您的项目，或者导致其他人的包、类等出现问题。
此外，您应该与您的客户（即使是您自己的公司）保持密切联系，并尝试并鼓励他们进行全面的验收测试。这符合他们的最大利益（尽管我发现一些公司反对这个想法，因为执行测试所需的时间很短，尽管如果产品不能完全执行它会节省大量时间他们想要什么）。
编辑
所以，是的，我想我想说的是：是的，我确实认为测试驱动开发是要走的路。我当然没有提到的另一件事是测试有助于记录代码这一事实。您将知道这些方法应该做什么，并且您将确定当您在以后的任何阶段进行更改时它们仍然可以执行。
于 2008-10-17T11:19:29.730 回答
8
我们的项目绝对使用单元测试。每个不是无脑 getter 和 setter 的类都经过单元测试。对您的代码进行功能测试使您可以随意重构，而不必担心一次会破坏 50 种不同的东西。
单元测试的另一个被低估的方面是它使算法的被忽视的方面浮出水面。我只花了两天时间使用正交数组编写和重写单元测试，因为每次我想出一个测试用例列表时，我都会发现技术负责人忽略了问题的另一个维度。
于 2008-10-18T04:01:19.350 回答
5
是的。我们使用 TDD 已经有一段时间了。不知何故，我们发现了 TDD，我们喜欢这种增量方法，以实现更好的代码质量。尽管在最初的拒绝曲线中，您认为在编写代码时进行一致和渐进的单元测试会减慢开发速度，但在许多方面都是必不可少的。由于正在逐步构建回归测试框架，因此很难编写重大更改。如果做得好，代码会更加健壮，并且对代码和整个项目的信心都会受到积极影响。
现在编写单元测试不仅仅适合精英。这应该是每个开发人员的责任。越晚在代码上发现错误，修复的成本就越高，也就越难找到。这很容易成为维护的噩梦。对单元测试有强有力的支持可以大大降低这种风险。
将单元测试和 TDD 的强大功能与配置良好的持续集成系统相结合，可以在项目的早期阶段快速发现问题。每天构建是避免未来和几乎可以肯定的麻烦的必要条件。
于 2008-10-17T11:13:29.773 回答
5
单元测试是有代价的。首先，您必须编写并验证所有额外的代码。然后你可能不得不在项目团队中推动昂贵的文化变革来接受单元测试。
这个价格可能值得为您的特定项目支付。该决定不应基于教条或轶事，而应基于对成本和收益的仔细分析。
于 2008-10-17T12:08:59.990 回答
2
严格来说不是 TDD，但我对我编写的每一段代码都进行了单元测试。我对它的看法与我对源代码控制和重构的看法相同；它们是您编写高质量代码所要做的事情。我不会想到不进行单元测试。
于 2008-10-17T12:20:04.057 回答
2
我们在一段代码像客户真正想要的那样工作之后进行单元测试。一开始我们做单元测试的速度太快了，当客户改变主意时（相信我），你经常不得不删除代码以及单元测试。这太耗时且成本高昂。我支持单元测试，但TDD对我们来说并不经济。
于 2008-12-17T13:21:15.593 回答
2
我无法想象现在在没有自动化测试的情况下进行项目（单元/集成等......）
其实我经常说
“如果这坏了，那不是我的错”
在处理没有测试的人们的代码时。
于 2009-08-25T09:49:33.677 回答
1
我发现 TDD 非常有用，但是一些开发人员直到编写一些新代码破坏了旧测试时才看到它的价值。
于 2008-10-17T11:23:07.383 回答
1
当你在论坛上提问时，很多人会说单元测试是“强制性的”，但实际上单元测试的考虑正如调查结果所示。有关更多参考资料/材料，请参阅http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2。
于 2008-12-17T21:47:25.570 回答
0
我有兴趣做这件事，但不知道如何开始我最终参与的大型项目......自 1996 年以来就没有参与过一个真正全新的项目！
于 2008-10-17T11:34:10.623 回答
0
我希望我可以在我的项目中更多地使用单元测试，并且我希望我的同事至少正在编写一些测试。:)
就我而言，启用单元测试和使用 TDD 实践需要付出相当高的代价。它主要依赖于工具，这些工具对于我们正在使用的框架来说是相当糟糕的。如果只需单击整个项目（或单击两次，以防我们目前需要特定测试）就可以执行单元测试，那会容易得多。我们现在使用的工具并没有真正得到回报——有时手动发现错误比运行测试更容易。
使用 Java，有更好的工具，所以你现在真的应该开始编写测试了！调试很糟糕，测试岩石，真的。
于 2008-10-17T12:54:01.850 回答
0
不幸的是不是每次。我们最关键的任务系统充满了单元测试，以确保他们做他们应该做的事情，并且不管开发人员如何都继续做。对于其他系统，大多数时候开发时间太短，无法将其花在编写测试上。（但最终赢得的时间是在调试上花费了两次。）
于 2008-10-17T13:16:07.280 回答
0
是的。除非客户在我头上拿着枪，以便在一天结束前将功能推出门外。
于 2008-10-18T02:59:38.693 回答
0
单元测试（我在这里考虑 JUnit）和 TDD 是当您使用新代码开始一个新项目时要走的路（您将需要更多类似 CI）。
但是，当您的新项目要修改一个充满紧密耦合类的旧代码库时，每个类中都有 5KLOC，那么单元测试很困难，并且大多数时候项目时间线不允许重构（或重写）。如果这是您即将开始的项目，我建议您阅读“使用遗留代码”以测试旧代码的策略。
于 2008-10-18T03:47:56.227 回答
0
在所有新的开发中，我们现在都做 TDD。对于遗留维护，我们创建失败的单元测试以暴露报告的缺陷并逐步建立一个库。
这是一种文化冲击，但当您意识到您将更多时间花在新开发上而花费更少时间寻找错误时，它确实会得到回报。
于 2008-12-10T19:20:57.630 回答
0
是的，只要我能。我必须支持我编写的代码，而且我知道在开发过程中花费的少量额外时间使我免于在发布后花费大量额外时间。
于 2009-10-11T17:18:30.253 回答
0
如果它值得写，那就值得测试。
于 2009-10-11T18:51:23.640 回答