有人告诉我,除了测试之外,我不应该在 rails_env 中运行我的 rspec 规范。
在生产或开发中运行规范有哪些潜在问题?我在两者中都运行规范。我通常在 dev 中运行规范,除非我正在测试使用资产管道的东西。我为此切换到生产环境,并花费 15 分钟预编译资产。与我当前的方法相比,使用测试环境有什么优势吗?
我搜索了答案,但没有解释为什么我不应该使用 dev 或 prod。
有人告诉我,除了测试之外,我不应该在 rails_env 中运行我的 rspec 规范。
在生产或开发中运行规范有哪些潜在问题?我在两者中都运行规范。我通常在 dev 中运行规范,除非我正在测试使用资产管道的东西。我为此切换到生产环境,并花费 15 分钟预编译资产。与我当前的方法相比,使用测试环境有什么优势吗?
我搜索了答案,但没有解释为什么我不应该使用 dev 或 prod。
在环境中运行测试套件(例如rspec)test
旨在隔离资源以解决安全问题,特别是数据库的完整性。测试通常会破坏或完全删除数据库中的数据。
对于所有资源也是如此。通过使用test
环境,您可以切断和模拟资源,从而防止您的测试破坏任何东西。
使用分离环境的原因有很多,但从根本上说,它是一种资源分离,在test
环境的上下文中,它是为了在确保生产资源和运行系统的安全性的同时启用应用程序的验证。
让我们明确一点,尤其是对于可能正在阅读这篇文章的 nubes:(RAILS_ENV=production
本地)与“在production
环境中”运行测试不同。我知道你(OP)知道这一点,但是在生产环境中运行测试的危险需要这个警告。
仅在 env 中运行有几个原因test
,通常与 DB 的处理有关:
其他原因与您已经推测的一致:
可能性太定制(对您的应用程序)建议最佳实践......但是,不用说,有许多“测试模式”设置可能需要配置时rails_ENV=test
你应该明确你的优先事项。为什么要运行规范?
我会说,大多数人都运行 2. 的规范,这确实应该在测试环境中进行,只是出于 NewAlexandrias 回答中给出的原因。
当您想在部署后检查 1. 时,运行规范对我来说似乎有点牵强。应该有更简单的方法。
当您部署时,您不确定 2. ... 那是过早的部署,您不应该这样做。