I was told that I shouldn't run my rspec specs in a rails_env other than test.
我被告知我不应该在rails_env中运行我的rspec规范而不是测试。
What are the potential problems running specs in production or development? I run specs in both. I usually run the specs in dev unless I'm testing something that uses the asset pipeline. I switch to production for that and spend 15 minutes pre-compiling assets. Are there any advantages to using the test environment over my current methods?
在生产或开发中运行规范的潜在问题是什么?我在两者中运行规格。我通常在dev中运行规范,除非我正在测试使用资产管道的东西。我转而投入生产并花费15分钟预编译资产。使用测试环境比我目前的方法有什么好处吗?
I searched for an answer but nothing explained why I shouldn't use dev or prod.
我搜索了一个答案,但没有解释为什么我不应该使用dev或prod。
3 个解决方案
#1
7
Running test suites (such as rspec) in a test environment is intended to isolate resources for security concerns, in particular the integrity of your databases. Tests often corrupt or entirely delete data in your databases.
在测试环境中运行测试套件(例如rspec)旨在隔离资源以解决安全问题,尤其是数据库的完整性。测试通常会破坏或完全删除数据库中的数据。
The same holds true for all resources. By using the test environment you are able to cut off and mock resources, thereby preventing you tests from corrupting anything.
所有资源都是如此。通过使用测试环境,您可以切断和模拟资源,从而防止测试破坏任何内容。
There are many reasons to use separate environments but fundamentally it is a separation of resources, and in the context of the test environment it is to enable the validation of your application while ensuring the safety of the production resources and running system.
使用单独环境的原因有很多,但从根本上说它是资源的分离,在测试环境的上下文中,它是在确保生产资源和运行系统的安全性的同时启用应用程序的验证。
#2
3
Let's be clear, especially for nubes that may be reading this post: RAILS_ENV=production (locally) is not the same as running test "in the production environment." I know you (OP) know that, but the danger of running tests in the production env warrant this warning.
让我们明确一点,特别是对于可能正在阅读这篇文章的nubes:RAILS_ENV =生产(本地)与在生产环境中运行测试不同。我知道你(OP)知道这一点,但是在生产环境中运行测试的危险值得警告。
There are several reasons to only run in the test env, generally relating to the handling of the DB:
有几个原因只能在测试环境中运行,通常与数据库的处理有关:
- Rspec builds a custom 'version' of the data in the DB, and operates upon that, persisting some changes back to the disk.
- Many test wipe out existing data, toward the end of test isolation and making things idempotent. This could wonk-up the data you're using to buildings out in test.
Rspec在数据库中构建数据的自定义“版本”,并对其进行操作,将一些更改保留回磁盘。
许多测试都会消除现有数据,直到测试隔离结束并使事物具有幂等性。这可能会将您正在使用的数据打造成测试中的建筑物。
other reasons are along them lines you've surmised already:
其他原因也是你已经推测出来的:
- your prod environment should not include gems that are used for testing. Why?:
- testing gems add more code that may need ot lod & run, needlessly, in the live app
- testing-related gems can introduce security holes into your production app.
测试宝石添加更多代码,可能需要在实时应用程序中不必要地运行和运行
与测试相关的宝石可以在您的生产应用中引入安全漏洞。
- certain assets may not test properly after they are 'compiled'.
- assets and other deploy-pipe-line precompile can be handled differently / turned off / etc, in service of the testing process.
- Certain APIs and services may be sandboxed, or stubbed, in test/staging, such as API calls to pay-per-use services, like email or reports.
您的产品环境不应包含用于测试的宝石。为什么?:测试宝石会添加更多代码,这些代码可能需要运行,不必要地,在实时应用中,与测试相关的宝石可能会在您的生产应用中引入安全漏洞。
某些资产在“编译”后可能无法正常测试。
在测试过程中,资产和其他部署管道预编译可以不同的方式处理/关闭/等。
某些API和服务可能在测试/暂存中被沙箱化或存根,例如对电子邮件或报告等按使用付费服务的API调用。
The possibilities are too-custom (to your app) to suggest a best-practice... but, needless to say, there are many 'test mode' settings that may need configuration when rails_ENV=test
可能性过于自定义(对您的应用程序而言)建议最佳实践...但是,不用说,当rails_ENV = test时,有许多“测试模式”设置可能需要配置
#3
0
You should get your priorities clear. Why do you run specs?
你应该明确你的优先事项。你为什么要运行规格?
- to be sure, that your environment xyz runs your code at all or
- to be sure, that your code does as it should
确保您的环境xyz完全运行您的代码或
可以肯定的是,您的代码可以正常运行
I would say, most ppl run specs for 2., and that really should take place in the test environment, just for the reasons given in NewAlexandrias answer.
我会说,大多数ppl运行规格为2.,这确实应该在测试环境中进行,只是出于NewAlexandrias答案中给出的原因。
When you want to check about 1. after deployment, running specs seems a bit farfetched to me. There should be simpler ways.
如果要在部署后检查1.运行规格对我来说似乎有点牵强。应该有更简单的方法。
When you deploy, and you are not sure about 2. ... thats premature deployment, something, you should not be doing.
当你部署,并且你不确定2.那就是过早部署时,你不应该这样做。
#1
7
Running test suites (such as rspec) in a test environment is intended to isolate resources for security concerns, in particular the integrity of your databases. Tests often corrupt or entirely delete data in your databases.
在测试环境中运行测试套件(例如rspec)旨在隔离资源以解决安全问题,尤其是数据库的完整性。测试通常会破坏或完全删除数据库中的数据。
The same holds true for all resources. By using the test environment you are able to cut off and mock resources, thereby preventing you tests from corrupting anything.
所有资源都是如此。通过使用测试环境,您可以切断和模拟资源,从而防止测试破坏任何内容。
There are many reasons to use separate environments but fundamentally it is a separation of resources, and in the context of the test environment it is to enable the validation of your application while ensuring the safety of the production resources and running system.
使用单独环境的原因有很多,但从根本上说它是资源的分离,在测试环境的上下文中,它是在确保生产资源和运行系统的安全性的同时启用应用程序的验证。
#2
3
Let's be clear, especially for nubes that may be reading this post: RAILS_ENV=production (locally) is not the same as running test "in the production environment." I know you (OP) know that, but the danger of running tests in the production env warrant this warning.
让我们明确一点,特别是对于可能正在阅读这篇文章的nubes:RAILS_ENV =生产(本地)与在生产环境中运行测试不同。我知道你(OP)知道这一点,但是在生产环境中运行测试的危险值得警告。
There are several reasons to only run in the test env, generally relating to the handling of the DB:
有几个原因只能在测试环境中运行,通常与数据库的处理有关:
- Rspec builds a custom 'version' of the data in the DB, and operates upon that, persisting some changes back to the disk.
- Many test wipe out existing data, toward the end of test isolation and making things idempotent. This could wonk-up the data you're using to buildings out in test.
Rspec在数据库中构建数据的自定义“版本”,并对其进行操作,将一些更改保留回磁盘。
许多测试都会消除现有数据,直到测试隔离结束并使事物具有幂等性。这可能会将您正在使用的数据打造成测试中的建筑物。
other reasons are along them lines you've surmised already:
其他原因也是你已经推测出来的:
- your prod environment should not include gems that are used for testing. Why?:
- testing gems add more code that may need ot lod & run, needlessly, in the live app
- testing-related gems can introduce security holes into your production app.
测试宝石添加更多代码,可能需要在实时应用程序中不必要地运行和运行
与测试相关的宝石可以在您的生产应用中引入安全漏洞。
- certain assets may not test properly after they are 'compiled'.
- assets and other deploy-pipe-line precompile can be handled differently / turned off / etc, in service of the testing process.
- Certain APIs and services may be sandboxed, or stubbed, in test/staging, such as API calls to pay-per-use services, like email or reports.
您的产品环境不应包含用于测试的宝石。为什么?:测试宝石会添加更多代码,这些代码可能需要运行,不必要地,在实时应用中,与测试相关的宝石可能会在您的生产应用中引入安全漏洞。
某些资产在“编译”后可能无法正常测试。
在测试过程中,资产和其他部署管道预编译可以不同的方式处理/关闭/等。
某些API和服务可能在测试/暂存中被沙箱化或存根,例如对电子邮件或报告等按使用付费服务的API调用。
The possibilities are too-custom (to your app) to suggest a best-practice... but, needless to say, there are many 'test mode' settings that may need configuration when rails_ENV=test
可能性过于自定义(对您的应用程序而言)建议最佳实践...但是,不用说,当rails_ENV = test时,有许多“测试模式”设置可能需要配置
#3
0
You should get your priorities clear. Why do you run specs?
你应该明确你的优先事项。你为什么要运行规格?
- to be sure, that your environment xyz runs your code at all or
- to be sure, that your code does as it should
确保您的环境xyz完全运行您的代码或
可以肯定的是,您的代码可以正常运行
I would say, most ppl run specs for 2., and that really should take place in the test environment, just for the reasons given in NewAlexandrias answer.
我会说,大多数ppl运行规格为2.,这确实应该在测试环境中进行,只是出于NewAlexandrias答案中给出的原因。
When you want to check about 1. after deployment, running specs seems a bit farfetched to me. There should be simpler ways.
如果要在部署后检查1.运行规格对我来说似乎有点牵强。应该有更简单的方法。
When you deploy, and you are not sure about 2. ... thats premature deployment, something, you should not be doing.
当你部署,并且你不确定2.那就是过早部署时,你不应该这样做。