为什么开发不写单元测试_单元测试–为什么不呢？

为什么开发不写单元测试

对于我们项目中的JUnit实现，我们已经为Sprint 2和Sprint 3落后了，在实现它们方面遇到了巨大挑战。该团队已获得有关JUnit实现和示例测试用例的所有知识演练。 我看不出该团队能够达到预期的JUnit覆盖率。 我们需要首先跟踪交付情况，并且可以计划在团队获得带宽时编写JUnit。 请让我们知道您的想法。

真的–您将再次给我该死的东西。 您项目的落后情况是否没有告诉您什么，是否甚至使您震惊，如果开发人员不测试他们的代码，实际上可能会出现较少的问题，并且项目可能会顺利进行。

这就是我一周前会做出的回应。 但是今天，我愿意进行合理的交谈，以了解使团队难以进行“自动化”单元测试的痛苦点（自动化是这里的关键）。 让我们回到单元测试的核心，甚至在此之前- 自测代码 。 引用马丁·福勒…

关于TestDrivenDevelopment （TDD），通常会谈到这些好处，但是将TDD和自检代码的概念分开是很有用的。 我认为TDD是一种特殊的做法，其好处包括产生自测代码。 这是一种很棒的方法，而TDD是我非常喜欢的一项技术。 但是，您也可以在编写代码后通过编写测试来产生自测试代码-尽管您只有在获得测试（并通过测试）后才能考虑完成工作。 自我测试代码的重点是您拥有测试，而不是获得测试的方式。

一遍又一遍地阅读本段内容，直到您牢记两个关键信息为止：a）您必须完成测试并通过测试，才能考虑完成工作； b）重要的一点是您拥有测试，而不是如何获得测试。 既然您已经充分理解了（希望），那么让我问一个简单的问题-开发人员是否在进行任何单元测试（再次不是自动化的）？ 如果答案为“否”，那么我有问题，并且很生气。

我是单元测试的忠实拥护者，我的第一份工作是在我的第一份工作上，那是在TDD上做的，是的，这是肾上腺素急促的多巴胺药（正如David H在他的播客中所说）。 当我们决定放弃该实现时，我看到了它的有效性，因为我们意识到它无法扩展。 我们只有6个月的开发时间，我们拥有许多LOC，并且拥有400多个测试用例的可靠测试套件。 当我们决定需要做一些根本不同的事情时，我们选择保留测试套件（我们以前使用NUnits）。 在接下来的2个月中，当我们编写新的实现时，这些测试用例就是我们的反馈循环。 我们的工作（由4个开发人员组成的团队）是确保所有400多个测试用例都变为绿色。 当我们看到所有的人都是绿色的那一天，我们知道当我们离开代码/实现时，我们正是在那儿（功能交付）。 重做实现的速度是因为我们对正在编写的新代码抱有信心-我们几乎立即被告知是否做对了或错了（不是按照定义的单元测试-但这是为了以后做） 。 然后，几年后的2008年，我们又做了同样的事情，我们重新实施了9个月x 25人的实施，花了3个月x 20人才能赶上并满足相同的功能交付。

在这种情况下，我读到一个项目处于落后状态，他们需要充满信心地走得更快，以赶上并满足交付时间表。 不进行单元测试（再次不说“自动化”），就像有人告诉我– Kapil，您正在开车去参加婚礼，您迟到了，现在您必须加快开车速度。 但是，与其增加更多的安全气囊，不如给他们提供更好的车轮，更好的刹车； 我们将拿走您今天拥有的1个安全气囊，并用旧的轮胎替换您的车轮。 现在，开车去，否则你不会结婚。 您认为我会怎么做–加快速度行驶，冒着生命危险或开始行驶甚至变得更慢，因为我希望自己成为妻子，因为我深深地知道我别无选择，只能缓慢行驶。 好吧，你明白了–虽然我可能要结婚，但她会因为毁了她完美的一天而对我生气很长时间。

如果延迟了这个项目，我还没有解决这个问题（我必须这样做），但是我可以打赌我的荒谬薪水是因为两件事– a）开发人员不断引入的“回归”和b）发送不完整的功能代码到发现缺陷的质量保证，然后全部归还给他们，在某些情况下，甚至在测试的客户端层中也发现了这些缺陷。 以我的经验，这就是我作为开发人员的理想日子过去：

1. 第一天
   1. 了解要求– 1小时
   2. 设计和实施以及单元测试-6小时
   3. 测试（集成+功能/系统）– 1小时
2. 第二天
   1. 重复第一天

而且，当我将代码交付给质量检查人员时，我几乎没有发现任何要修复的缺陷，因此我会日复一日地继续这一周期。 如果有人做出错误的估计，时间将会延长，但是活动总是保持不变，并且每次花费的时间总是以一定比例增加。 我已经看到开发人员这样做。 但是，最近，我看到了开发人员，这就是他们今天的样子：

1. 第一天
   1. 实施新故事-12小时
2. 第二天
   1. 从第1天到4小时修复缺陷
   2. 实施新故事-12小时

好了，您已经看到，在第2天，开发人员正在解决其技术债务，并且他们正在努力追赶。 这个无休止的循环称为“技术债务旋风”是无法恢复的。 该项目将交付一天，而人们将被烧死。 开发人员指责估计，而建筑师则指责技能，培训和纪律。 好吧，我们称团队失败了。

作为开发人员，我会问您-为什么您不想获得高水平？ 您为什么不想在知道代码提交不会破坏其他事情的状态下保持信心？ 为什么不进行单元测试？

翻译自: https://www.javacodegeeks.com/2014/09/unit-testing-why-not.html

为什么开发不写单元测试