测试已成为强制性的（不再有任何借口）

关于自动化测试的价值以及为什么在整个软件产品的生命周期中必须进行自动化测试，有很多文章。

大多数人和团队完全同意这一说法，那么出了什么问题呢？

这只是一个原型

这似乎是一个有效的声明，但是如果我们考虑一个原型将其投入生产的次数，那么它就不是那么有效。 实际上，大多数原型代码库最终都投入生产，因为这是原型的目标。 在原型阶段添加测试绝对有道理。

太难测试

是的，在某些情况下由于限制确实很难进行测试。 例如，android和iphone仿真器无法为您设置加速度计事件，或者您使用的服务根本没有提供任何测试实用程序或测试环境。 即使模拟不能构成绝对的测试用例，它也确实可以帮助您制定有关工作方式的规范。 另一种情况是测试由于代码库而难以实现。 将此视为表明事情还不够简单的指标。 如果这只是您的代码库，那么您很幸运，这取决于您使其更具可测试性和更简单。

要做的事太多，时间太少

这是我们最薄弱的地方，也是我们最容易屈服的地方。 假设您开发智能手机应用程序。 如果进行手动测试，则每个错误将花费您3-5分钟。 启动仿真器或什至更糟地将其部署到物理设备，加载应用程序并按一些按钮以创建事件，并在出现错误的情况下重复并释放其他3-5分钟。

如果开发服务器应用程序，情况可能会变得更糟。 连接到服务器，上载应用程序，检查上载是否成功，然后手动测试它是否可以正常运行，如果出现错误，请重复并再次花费一些时间。 还请记住，在涉及多个开发人员的项目中，更容易发生错误。

我们倾向于认为最好的情况将会发生，即一切都会按预期进行。 它可能在大多数时间都有效，但是如果出现问题，您可能会大失所望。 我们最终陷入了“可以的，只需上传另一个版本”模式。 下次发生这种情况时，只需手动测试直到一切都好，就可以算出您最终失去了多少时间。 然后估算在这种情况下要花费多少时间测试以及您要赢得多少时间。

一切变化如此Swift

是的，处于初始阶段的项目在两个月内将具有与初始阶段完全不同的代码库。 但是，由于进行了重大更改，因此可能会发生更多错误。 最少的测试可确保基本功能继续运行。

总而言之，测试并不像以前那样困难。 如今，我们使用的几乎所有服务或实用程序都带有一些测试实用程序。 随着软件行业变得更具挑战性，没有测试的代码库将不复存在。 选择您想要的任何方法，但只需执行即可。 您的生活将变得更加轻松。

翻译自: https://www.javacodegeeks.com/2016/04/testing-become-mandatory-no-excuses.html