为什么不编写单元测试用例的10个理由！

最后，这里是一个博客，支持所有认为编写单元测试用例是在浪费时间的人。 让我们来看看..

以下是一些原因：

1. 您是Neo（来自《黑客帝国》），是“被选者”

   您可以看到代码以绿色二进制文件的形式执行。 您会感觉到代码并了解每个用例，您是如此的精巧，您不需要任何单元测试用例的安全网来确定问题； 您可以用肉眼看到它们！

2. 您的学士学位/产品负责人是克里希纳勋爵的第10个化身

   所以他告诉你的只是绝对的真理！ 故事中没有混乱，讨论和模棱两可，因为那些是上帝的话！ 你怎么能不理解甚至质疑神的话呢？ 当什么都没有丢失时，为什么需要愚蠢的单元测试用例来识别丢失的用例！

3. 您的团队已经掌握了预测未来的古老艺术。

   您的团队中有Oracle，您已经预见了将来将会发生的所有变化。 您已经窥视了消费者的内心！

   当您已经处理完所有更改后，为什么您的代码也会更改？

   为什么会有任何重构？

   为什么会有任何增强要求？

   您已经为现在和将来编写了完美的代码，那么为什么要浪费时间在编写单元测试用例上呢？

   您为什么不愿意知道您的更改可能对其他模块产生的影响？

4. 您知道您的项目永远不会进入维护阶段。

   您能告诉我您的代码将永远不会进入维护阶段吗？ 有任何猜测吗？

   是的，它永远不会被释放.. !! 您应该只继续编码2年，而无需遵循任何敏捷或测试原则！

   我很确定 结果，该项目将永远无法进行。 问题解决了。 没有实时代码..没有维护..没有重构..没有错误修复..没有变化..容易上手..

   （如果它以某种方式成功上线，请切换公司）

5. 您是一家邪恶的咨询公司，仅通过维护项目来获利！

   您的公司竞标了一个疯狂的时间表和廉价的计费项目。 他们非常了解，这几乎是一项没有利润的交付项目的投资，因为回报很快就会到来！

   怎么样？

   他们知道，将要产生的东西将是废话！ 当然，它根本没有单元测试用例！

   结果：该项目肯定会交付，但是要修复其错误/维护它，所需的工作量将比构建它所需的工作高10倍！ 而且由于您已经构建了它，所以确实很糟糕； 只有您知道如何解决它！

   而且由于没有单元测试用例，因此没有人能够分析更换一个运动部件时会发生什么！ 更好！！ 为什么？ 因为那样的话，在修复较旧的bug时会引入更多的bug ！！！ 结果; 更多账单！

   （muwhahahaa..haahaaa……邪恶的笑声！）

6. 你知道你不会在身边

   您将不会在项目或公司中呆很长时间，以查看项目是否失败。 最佳用例：您正在履行通知期！ 您知道您永远不会看到您今天正在编写的代码，如果以后出现问题，这也不是您的责任！

   （确保您在切换公司后更改了电子邮件地址和电话号码，并且已收到放宽信）

7. 复仇最好是冷服！

   作为程序员，您一生都在尝试修复没有或只有很少单元测试的旧代码中的错误。 您一生的一半被浪费在识别正在发生的事情上，而另一半则试图解决您的更改造成的混乱！

   你受够了!! 现在是时候让其他尘世生物与您一样遭受地狱了！ 因此，您无需编写任何单元测试用例，让稍后将要处理代码的人员可以理解您的痛苦和痛苦！！

   最后，您将被报仇！

第8、9和10个理由，我请你们弄清楚，我敢肯定您还必须有更多的借口来编写单元测试用例。

如果您没有这些原因，那么最好立即开始编写单元测试用例！！

PS：我写10个理由仅仅是因为听起来很酷

干杯…

参考： 为什么不编写单元测试用例的10个理由！ 从我们的JCG合作伙伴 Anirudh Bhatnagar在anirudh bhatnagar博客上获得。

翻译自: https://www.javacodegeeks.com/2013/10/10-reasons-why-you-should-not-write-unit-test-cases.html