¿Por qué debería ejecutar las especificaciones de rspec en mi aplicación Rails solo en un entorno de prueba, no dev o prod?

Question

Me dijeron que no debería ejecutar mis especificaciones de rspec en un rails_env que no sea prueba.

¿Cuáles son los posibles problemas al ejecutar las especificaciones en producción o desarrollo? Ejecuto especificaciones en ambos. Por lo general, ejecuto las especificaciones en dev a menos que esté probando algo que utiliza la canalización de activos. Paso a la producción para eso y paso 15 minutos antes de compilar los activos. ¿Hay alguna ventaja en usar el entorno de prueba sobre mis métodos actuales?

He buscado una respuesta, pero nada explica por qué no debo usar dev o prod.

Answer 1

Operando de pruebas (como rspec) en un entorno test pretende aislar los recursos por motivos de seguridad, en particular, la integridad de las bases de datos. Las pruebas a menudo corrompen o borran completamente los datos en sus bases de datos.

Lo mismo vale para todos los recursos. Al utilizar el entorno test, puede cortar y simular recursos, lo que evita que las pruebas dañen cualquier cosa.

Existen muchas razones para utilizar entornos separados pero fundamentalmente es una separación de recursos, y en el contexto del entorno test es para permitir la validación de su aplicación y garantizar la seguridad de los recursos de producción y del sistema en ejecución.

Answer 2

Seamos claros, especialmente para nubes que puedan estar leyendo este post: RAILS_ENV=production (localmente) no es lo mismo que correr prueba "en el entorno production." Sé que (OP) lo sabe, pero el peligro de ejecutar pruebas en el entorno de producción justifica esta advertencia.

Hay varias razones para sólo se ejecutan en el test env, en general, en relación con el manejo de la base de datos:

• Rspec construye una costumbre 'versión' de los datos en la base de datos, y opera sobre aquella, persistiendo algunos cambios en el disco.
• Muchas pruebas borran los datos existentes, hacia el final del aislamiento de la prueba y haciendo las cosas idempotentes. Esto podría sacar los datos que está utilizando a edificios en prueba. otros

razones son lo largo de ellos líneas que han conjeturaron ya:

1. su entorno de producción no debe incluir piedras preciosas que se utilizan para la prueba. ¿Por qué ?:
   • gemas pruebas añadir más código que puede necesitar ot lod & plazo, innecesariamente, en la aplicación en vivo
   • gemas relacionados con las pruebas pueden introducir los agujeros de seguridad en su aplicación de producción.
2. Es posible que ciertos activos no se prueben correctamente después de que se hayan "compilado".
3. activos y otra precompilación deploy-pipe-line pueden manejarse de manera diferente/apagar/etc, en servicio del proceso de prueba.
4. Ciertas API y servicios pueden ser con espacio aislado, o anulados, en prueba/puesta en escena, como llamadas API a servicios de pago por uso, como correos electrónicos o informes.

Las posibilidades son demasiado personalizado (a su aplicación) para sugerir una mejor práctica ... pero, ni que decir tiene, hay muchos ajustes del modo de prueba '' que pueden necesitar configuración cuando rails_ENV=test

Answer 3

Debes aclarar tus prioridades. ¿Por qué ejecutas las especificaciones?

1. para estar seguro, de que su entorno XYZ se ejecuta el código en absoluto o
2. para estar seguro, de que su código hace como debería

especificaciones

yo diría, la mayoría de PPL duración de 2 ., y eso realmente debería tener lugar en el entorno de prueba, solo por las razones dadas en la respuesta de NewAlexandrias.

Cuando desee comprobar 1. después de la implementación, ejecutar las especificaciones me parece un poco inverosímil. Debería haber formas más simples.

Cuando realiza la implementación, y no está seguro acerca de 2. ... esa implementación es prematura, algo que no debería estar haciendo.