测试

我特别喜欢测试这项工作，事实上如果不加测试，我根本就不愿意直接在代码库中编写代码。

如果您的整个应用程序只需要执行一项任务（我在学校里的实验性项目就是这样），那么手动测试即可解决问题，我以前也一直习惯于这种方式。但是，当应用程序当中包含上百种功能，情况又会如何？我不想拿出大量时间挨个测试，而且我也知道自己肯定会忘掉某些需要测试的部分。这绝对会是一场噩梦。

这时候，我们就该请出测试自动化方案了。

在我看来，测试跟记录文档差不多。测试的过程，就是记录我对于代码的假设是否正确的过程。测试会告诉我，我自己（或者是当初写下代码的开发）当时希望代码如何运行，以及认为哪里有可能出问题。

因此，现在再编写测试时，我会牢记以下两点：

1．演示如何使用我正在测试的类/函数/系统。

2．展示我认为可能出问题的部分。

第一条相信很多朋友都能理解，毕竟在大多数情况下，我们需要测试的其实是行为，而非实现。

但我个人总会忽略第2条，即bug可能出现在哪里。

因此，每当我发现bug时，我都会确保代码修复程序在相应的测试（也就是回归测试）当中记录下其它有可能引发错误的方式。

当然，编写这类测试本身并不能提供代码质量，只有真正编写代码才会真正影响质量。不过我从阅读测试结果当中获得的见解，确实能够帮助自己编写出更好的代码。

这就是测试的宏观意义。

除此之外，测试还肩负着另一项重要使命：确定部署环境。

大家可能拥有完美的单元测试，但如果没有进行系统测试，就有可能发生以下情况：锁到底是好的，还是坏的？

对于经过良好测试的代码也是如此：如果您的机器上没有其需要的库，代码就会崩溃。

· 您开发所在的机器环境。（‘一切都能在我的机器上正常运行！’）

· 您测试所在的机器环境。（可能就是您开发所使用的那台机器。）

· 最后，您部署所在的机器环境。（请一定换一台别的机器。）

如果测试与部署机器间的环境不匹配，那一般都会出点问题。而这，正是部署环境的意义所在。

我们在自己的机器上使用docker构建本地开发环境。

在这套开发环境当中安装有一组库（及开发工具），我们则以此为基础安装已经编写完成的代码。所有与其它依赖系统相关的测试，都在这里完成。

然后是beta测试/分段环境，其与生产环境完全一致。

最后是生产环境，也就是负责运行代码并为实际客户提供服务的机器。

我们的基本思路是努力捕捉那些不会在单元与系统测试中出现的错误。例如，请求与响应系统之间的API不匹配问题。

我猜个人项目或者小型企业的情况可能有所不同，毕竟并不是每个人都有资源来设置自己的一套基础设施。但是，如果大家愿意使用AWS以及Azure等云服务，这里提到的方法仍然适合各位。

大家可以为开发以及生产环境设置单独的集群。AWS ECS利用docker镜像进行部署，因此各环境之间相对一致。比较棘手的部分，就是如果与其它AWS服务顺利整合。例如，我们是否从正确的环境中调用了正确的端点？

大家甚至可以更进一步：为其它AWS服务下载备用容器镜像，并利用docker-compose命令设置完整的本地环境。这样能够加速反馈循环。

如此一来，当我的附带项目启动并开始运行之后，我就能积累到更多经验心得。