我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。


当前回答

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here

其他回答

当涉及到重构或重写一段代码时,单元测试也特别有用。如果您有良好的单元测试覆盖率,您就可以满怀信心地进行重构。如果没有单元测试,通常很难确保您没有破坏任何东西。

单元测试很像去健身房。你知道这对你有好处,所有的争论都有意义,所以你开始锻炼。刚开始有一种冲动,这很好,但几天后你开始怀疑是否值得这样做。你每天花一个小时换衣服,在仓鼠转轮上跑步,你不确定除了腿和手臂疼痛之外,你真的得到了什么。

然后,也许一两周后,就在疼痛消失的时候,一个重要的截止日期开始来临。你需要把醒着的每一个小时都用来完成“有用的”工作,所以你要去掉无关紧要的事情,比如去健身房。你改掉了这个习惯,当截止日期结束的时候,你又回到了起点。如果你设法回到健身房,你会觉得和你第一次去的时候一样酸痛。

You do some reading, to see if you're doing something wrong. You begin feel a little bit of irrational spite toward all the fit, happy people extolling the virtues of exercise. You realize that you don't have a lot in common. They don't have to drive 15 minutes out of the way to go to the gym; there is one in their building. They don't have to argue with anybody about the benefits of exercise; it is just something everybody does and accepts as important. When a Big Deadline approaches, they aren't told that exercise is unnecessary any more than your boss would ask you to stop eating.

所以,回答你的问题,单元测试通常是值得付出努力的,但是所需的努力量对每个人来说都不一样。如果你在一家不重视代码质量的公司处理意大利面条式的代码库,那么单元测试可能需要付出巨大的努力。(许多经理会歌颂单元测试,但这并不意味着他们会在关键时刻支持单元测试。)

如果你正试图将单元测试引入到你的工作中,并且没有看到你所期待的所有阳光和彩虹,不要责怪自己。你可能需要找一份新工作来真正让单元测试为你工作。

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

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

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

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

我在其他任何答案中都没有看到这一点,但我注意到的一件事是,我可以更快地调试。你不需要通过正确的步骤序列深入到你的应用程序中,只发现你犯了一个布尔错误,需要重新做一遍。使用单元测试,您可以直接进入正在调试的代码。

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

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