python测试中会反映什么问题?

我把测试当做是文档。这是我对代码预期效果的文档。测试告诉我，我(或我之前的人)如何期望代码来工作，以及他们认为事情会出错的地方。所以，当我现在编写测试时，我会记住这一点：

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

展示出所有我认为可能会出错的内容。

上述的一个必然结果是，在大多数情况下，我测试的是行为，而不是实现。

我在#2中漏掉的东西就是bug的来源。

因此，每当我发现一个bug时，我都会确保代码修复程序有相应的测试(称为回归测试)来记录信息：这是另一种可能出错的方法。

但是，仅仅编写这些测试并不能提高代码质量，需要实际编写代码。但是我从阅读测试中获得的见解能帮助我写更好的代码。

但是，这不是唯一一种要做的测试。接下来就是部署环境登场的地方。

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

首先是你用来开发的机器(所有“它在我的机器上能正常工作!”这类meme(梗)的来源)。

其次是你用来测试的机器(可能与你用来开发的机器相同)。

最后，有你用来部署的机器(请不要让它与你用来开发的机器相同)

如果测试和部署机器之间的环境不匹配，你就麻烦了。这就是部署环境的用武之地。

我们的机器上有本地开发，它位于docker中。

我们有一个开发环境，其中机器安装了一组库(和开发工具)，我们在上面安装在这些库上编写的代码。其他依赖系统的所有测试都可以在这里进行。

然后是beta / stage环境，它与生产环境完全一样。

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

目的是尝试捕获单元和系统测试发现不了的bug。例如，请求和响应系统之间的API不匹配。

我想个人项目或小公司的情况会有很大不同。并非每个人都有资源来部署自己的基础设施。但是，这个想法对于AWS和Azure等云提供商的服务也适用。

你可以为开发和生产设置单独的集群。AWS ECS使用docker镜像进行部署，因此各环境之间相对一致。棘手的一点是其他AWS服务之间的集成。你是否从正确的环境中调用了正确的端点?

你甚至可以更进一步：为其他AWS服务下载备用容器映像，并使用docker-compose设置本地完整环境。这样能加速反馈循环。

好啦！今天的分享到这里就结束了，希望大家持续关注马哥教育官网，每天都会有大量优质内容与大家分享！