我把测试当做是文档。这是我对代码预期效果的文档。测试告诉我,我(或我之前的人)如何期望代码来工作,以及他们认为事情会出错的地方。所以,当我现在编写测试时,我会记住这一点:
演示如何使用我正在测试的类/函数/系统。
展示出所有我认为可能会出错的内容。
上述的一个必然结果是,在大多数情况下,我测试的是行为,而不是实现。
我在#2中漏掉的东西就是bug的来源。
因此,每当我发现一个bug时,我都会确保代码修复程序有相应的测试(称为回归测试)来记录信息:这是另一种可能出错的方法。
但是,仅仅编写这些测试并不能提高代码质量,需要实际编写代码。但是我从阅读测试中获得的见解能帮助我写更好的代码。
但是,这不是唯一一种要做的测试。接下来就是部署环境登场的地方。
对于经过良好测试的代码也是如此:如果你的机器上没有所需的库,则会崩溃。
首先是你用来开发的机器(所有“它在我的机器上能正常工作!”这类meme(梗)的来源)。
其次是你用来测试的机器(可能与你用来开发的机器相同)。
最后,有你用来部署的机器(请不要让它与你用来开发的机器相同)
如果测试和部署机器之间的环境不匹配,你就麻烦了。这就是部署环境的用武之地。
我们的机器上有本地开发,它位于docker中。
我们有一个开发环境,其中机器安装了一组库(和开发工具),我们在上面安装在这些库上编写的代码。其他依赖系统的所有测试都可以在这里进行。
然后是beta / stage环境,它与生产环境完全一样。
最后,生产环境,它们是运行代码并为实际客户提供服务的机器。
目的是尝试捕获单元和系统测试发现不了的bug。例如,请求和响应系统之间的API不匹配。
我想个人项目或小公司的情况会有很大不同。并非每个人都有资源来部署自己的基础设施。但是,这个想法对于AWS和Azure等云提供商的服务也适用。
你可以为开发和生产设置单独的集群。AWS ECS使用docker镜像进行部署,因此各环境之间相对一致。棘手的一点是其他AWS服务之间的集成。你是否从正确的环境中调用了正确的端点?
你甚至可以更进一步:为其他AWS服务下载备用容器映像,并使用docker-compose设置本地完整环境。这样能加速反馈循环。
文章转载于马哥教育官网!
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。