你在专业项目中使用单元测试吗？

Question

我们即将开始项目的一个新部分，似乎对单元测试并不感兴趣（并且不觉得他们已经体验过TDD）。我相信这几乎是必不可少的，它使维护更容易。 那你有什么看法？

感谢

BTW：这是一个语言无关的问题，但新项目是Java。

Answer 1

绝对单元测试用于我们的项目。每个不是没脑子的getter和setter的类都经过了单元测试。通过为您的代码进行功能测试，您可以随意重构，而无需担心会一次破解50个不同的事物。

单元测试的另一个被低估的方面是它将一个算法忽略的方面带到表面。我花了两天的时间用正交数组编写和重写单元测试，因为每次我提出一个测试用例列表时，我发现了另一个被技术负责人忽略的问题。

Answer 2

是的。我们现在一直在使用TDD。不知何故，TDD已经发现了我们，我们喜欢这种渐进式方法，以获得更好的代码质量。尽管最初的拒绝曲线在哪里，你认为它会减缓开发的一贯和渐进的单元测试，而在许多方面编写代码是必不可少的。由于逐步构建的回归测试框架，写入重大更改非常困难。如果做得对，代码更加健壮，代码和整个项目的信心受到积极影响。

时下的写作单元测试不仅仅是一个精英。它应该是每个开发者的责任。后面的代码中发现一个错误，它将花费更多的代价来修复，并且更难以找到它。这很容易成为维修的噩梦。强有力的单元测试支持极大地降低了这种风险。

将单元测试和TDD的强大功能与配置良好的持续集成系统相结合，可以在项目的早期阶段快速发现问题。日常生成是避免未来和几乎肯定麻烦的必要条件。

Answer 3

我发现单元测试不仅仅是一件有用的事情，它也是开发人员的责任。如果你发布的代码没有写出来通过一套有效而全面的单元测试，你很可能会延误你的项目，或者在别人的软件包，课程等中引起问题。

另外，你应该与您的客户（即使是您自己的公司）保持密切联系，并尝试并鼓励他们进行全面的验收测试。这符合他们的最佳利益（尽管我发现一些公司对这个想法有抵触情绪，因为执行测试需要短时间的时间花费，尽管如果产品没有准确地完成测试，可以节省大量的时间他们想要什么）。

编辑

所以，是的，我想我想说的是这一点：是的，我确实看到Test Driven Development的路要走。另一件我没有提到的事情是测试帮助记录代码。你会知道这些方法应该做什么，并且当你在后期进行修改时，你会确信他们仍然会这样做。

Answer 4

我发现TDD确实很有用，但是有些开发人员在编写一些新的代码之前没有看到它的价值。

Answer 5

我对这样做感兴趣，但不知道如何开始做大型项目，我最终加入了部分路径......自从回到以来，没有参与到项目的真正新开端中1996年！

Answer 6

单元测试是有代价的。首先，你必须编写和验证所有额外的代码。然后你可能不得不在项目团队中推动昂贵的文化变革，以接受单元测试。

这个价格很值得为您的特定项目付出代价。这个决定不应该基于教条或轶事，而应该仔细分析成本和收益。

Answer 7

严格地说不是TDD，但是我对每一段代码都进行了单元测试。我认为它和我想源代码控制和重构的方式一样;他们是你只需做来编写优质代码。我不会想到单元测试不是。

Answer 8

我希望我可以在我的项目中使用更多的单元测试，并且我希望我的同事至少编写了一些测试。 :)

在我的情况下，启用单元测试和使用TDD实践的代价相当高。它主要依赖于工具，这对我们正在使用的框架来说相当糟糕。如果只通过一次点击就可以完成整个项目的单元测试（或者点击两下，以防我们现在需要特定的测试），那将会容易得多。我们现在使用的工具并没有真正的回报 - 有时候更容易手动发现错误，而不是运行测试。

使用Java，有更好的工具，所以你真的应该开始写测试吧！调试吮吸，测试岩石，真的。

Answer 9

不幸的是不是每次。我们的大多数关键任务系统都充满了单元测试，以确保他们做他们应该做的事情，并且不管开发人员如何都要继续这样做。 对于其他系统，大部分时间开发时间太短，无法用于编写测试。 （但最后赢得的时间在调试上花费了两次。）

Answer 10

是的。除了一个客户在我的头旁有一把枪的情况下，在一天结束的时候将功能从门外取出。

Answer 11

单元测试（我在想JUnit在这里）和TDD是当你用新代码开始一个新项目（并且你需要更像CI）时要走的路。

但是，当你的新项目要修改一个旧的代码库，每个代码都包含5KLOC的紧密耦合类时，单元测试是困难的，大部分时间项目时间线不允许重构（或者改写）。如果这是您即将开始的项目，我建议您阅读“使用遗留代码”来测试旧代码的策略。

Answer 12

在所有新的开发中，我们现在做TDD。对于传统维护，我们创建失败的单元测试来揭示报告的缺陷并逐步建立一个库。

这是一种文化冲击，但是当你意识到你在新的开发中花费更多时间并且花费更少的时间寻找错误时，它确实会得到回报。

Answer 13

我们在部分代码工作后进行单元测试，就像客户真正的愿望一样。起初我们做单元测试的速度太快了，当客户改变主意时（它发生了，相信我），你经常不得不删除代码以及单元测试。这太费时费钱了。我是单元测试，但TDD对我们来说并不经济。

Answer 14

当你在论坛上提问时，很多人会说单元测试是“强制性”的，但实际上单元测试考虑的结果显示的是调查结果。有关更多参考资料/材料，请参阅http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2。

Answer 15

我无法想象一个项目现在的工作没有自动化测试（单位/集成等）

事实上，我经常说

“如果这个突破，它不是我的错”

当工作在没有测试的人的代码。

Answer 16

是的，只要我可以。我必须支持我编写的代码，并且我知道，在开发过程中花费的额外时间适中，这使我无法在发布后花费额外的时间。

Answer 17

如果值得写作，值得测试。