我是一名维护工程师，负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时，我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试，那么对代码库的更改就会更容易、更快。(与此同时，代码库将处于更好的状态)..

我认为，在编写api或框架时，单元测试非常有用，因为这些api或框架必须持续多年，并由原始编码器以外的人使用/修改/发展。

单元测试非常值得最初的投资。自从几年前开始使用单元测试以来，我发现了一些真正的好处:

回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化，要么工作，要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报，试试吧!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事，我认为你最好的办法是迎合他们的愿望，让他们做出高质量的软件。有许多研究表明，它能发现漏洞，如果他们关心做好工作，这对他们来说就足够了。

如果您试图说服管理层，您将很可能不得不做一些成本/收益推理，说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内，比如失去客户的信心等等。

Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.

在探索新的框架或代码库时，我最喜欢的一个技巧是为“它”编写单元测试，以发现事物是如何工作的。这是一个学习新事物的好方法，而不是阅读枯燥的文档:)

关于这个话题，我写了一篇很大的博客文章。我发现单靠单元测试是不值得的，而且通常在截止日期临近时就会被削减。

与其从“测试后验证”的角度来讨论单元测试，我们应该看看在实现之前编写规范/测试/想法时所发现的真正价值。

这个简单的想法改变了我写软件的方式，我不会回到“旧的”方式。

测试优先开发如何改变了我的生活

我曾多次尝试单元测试，我仍然相信，考虑到我的情况，这是值得的。

我开发网站，其中很多逻辑涉及在数据库中创建、检索或更新数据。当我为了单元测试的目的而尝试“模拟”数据库时，它变得非常混乱，似乎有点毫无意义。

当我围绕业务逻辑编写单元测试时，从长远来看它从未真正帮助过我。因为我主要独自从事项目工作，我倾向于直观地知道哪些代码区域可能会受到我所从事的工作的影响，并且我手动测试这些区域。我希望尽可能快地向客户交付解决方案，而单元测试通常看起来是浪费时间。我列出了手动测试，并亲自完成它们，并在执行过程中标记它们。

我可以看到，当一个开发团队在一个项目中工作并互相更新代码时，这可能是有益的，但即使这样，我认为如果开发人员具有高质量，良好的沟通和编写良好的代码通常就足够了。