测试？它们是给那些不会写代码的人准备的！
这一部分讨论了自动化测试的另一个明显可能性——根本不编写自动化测试。也许甚至根本不进行测试。这可行吗？
根本不测试是我们可能做出的选择，这可能并不像听起来那么愚蠢。如果我们将测试定义为在目标环境中验证某些结果是否实现，那么像深空探测器这样的东西在地球上无法真正测试。充其量，我们在测试期间模拟目标环境。大型 Web 应用程序很少能用真实的负载配置文件进行测试。拿任何一个大型 Web 应用程序，向它发起一亿用户——所有这些用户都在做无效的事情——看看大多数应用程序的表现如何。它可能不如开发者测试所建议的那样好。
有一些开发领域我们可能会看到较少的自动化测试：
-
数据迁移的提取、转换和加载（ETL）脚本：
ETL 脚本通常是一次性事务，用于解决某些数据的特定迁移问题。为这些脚本编写自动化测试并不总是值得的，而是对一组类似的源数据进行手动验证。
-
前端用户界面工作：
根据编程方法，为前端代码编写单元测试可能具有挑战性。无论我们采取什么方法，评估视觉外观和感觉目前无法自动化。因此，通常对用户界面的候选版本进行手动测试。
-
基础设施即代码脚本：
我们的应用程序需要部署在某个地方才能运行。最近的一种部署方法是使用
Terraform等语言通过代码配置服务器。这是一个目前还不容易自动化测试的领域。
那么，当我们放弃测试自动化，甚至根本不进行测试时，实际会发生什么呢？
如果我们在开发过程中不做测试，会发生什么？
我们可能认为根本不测试是一个选项，但实际上，测试总会在某个时候发生。我们可以用一个时间线来说明测试可能发生的点：
测试优先方法将测试尽可能提前——这种方法称为左移——在缺陷可以廉价且轻松地纠正时进行。认为我们不会测试只是将测试推到了最右边——在用户开始使用功能之后。
最终，所有用户关心的代码最终都会被测试。也许开发者不测试它。也许测试会落到另一个专门的测试团队，他们会编写缺陷报告。也许缺陷会在软件运行期间被发现。最常见的是，我们最终将测试外包给用户自己。
让用户为我们测试代码通常是一个坏主意。用户信任我们提供解决他们问题的软件。每当我们的代码中的缺陷阻止这种情况发生时，我们就会失去这种信任。信任的丧失会损害企业的三个 R：收入、声誉和保留率。用户很可能会转向另一个供应商，他们的代码经过更好的测试，实际上解决了用户的问题。
如果在我们发布之前有任何测试我们工作的可能性，我们应该抓住这个机会。我们越早在工作中建立测试驱动的反馈循环，就越容易提高工作的质量。
在讨论了何时测试我们的软件之后，让我们转向在哪里测试它。给定软件的整体设计，我们应该从哪里开始测试？下一部分将回顾一种从设计内部开始并向外扩展的测试方法。