¿Deberían las pruebas de unidades de Rails golpear la base de datos o no?

He estado escribiendo pruebas para mi aplicación de Rails. Yo uso TestUnit para la unidad, así como las pruebas funcionales. Y también uso pepino para pruebas de GUI.

Pero creo que http://www.dcmanges.com/blog/rails-unit-record-test-without-the-database dice que es mejor que las pruebas unitarias no lleguen a la base de datos.

Estoy de acuerdo en que golpear la base de datos toma un tiempo considerable. Ya uso spork para reducir la carga del entorno.

¿Cuál es la mejor práctica cuando se trata de probar una aplicación de Rails?

Este es uno de los casos en los que no deberías colgarte demasiado de los nombres. Rails se refiere a las pruebas que ejercitan los modelos de ActiveRecord como pruebas de “unidad”, en gran parte porque son las pruebas de nivel más bajo que admite directamente el marco. De acuerdo con la tradición de las pruebas, a lo que admito que tiendo a dividirme de manera bastante consistente, las pruebas unitarias no deben tener dependencias externas a la unidad sometida a prueba; Esto significa cosas como mecanismos de persistencia, es decir, la base de datos.

Dicho esto, probar los modelos ActiveRecord de cualquier complejidad sin la base de datos rápidamente hará que quieras comerte las manos. Rails asume que usted usa la base de datos para las pruebas; Así es simplemente la forma en que se escribe el marco. Puede intentar eliminar todo, pero eventualmente fallará, ya que terminará jugando en las partes internas de las asociaciones de ActiveRecord (no para los débiles de corazón). Puede intentar extraer todo el código no relacionado con la persistencia en módulos separados que prueben sin la base de datos, pero creará una complejidad innecesaria.

No trates de luchar contra el marco. ActiveRecord y ActionController tienen patrones muy específicos de uso esperado, tanto en producción como en pruebas. Rails, después de todo, tiene que ver con la convención. Si sigues el patrón de uso, harás mucho menos trabajo y te frustrarás mucho menos que si luchas contra las convenciones para mantener los ideales de prueba de unidad. Si te hace sentir mejor, considera que tus pruebas ActiveRecord son pruebas “modelo” y que tus pruebas funcionales son pruebas “controlador” (esta es la terminología que rspec usa, por cierto).

Dicho todo esto, no debe acceder a la base de datos innecesariamente en sus pruebas modelo (o especificaciones). Algunas validaciones, como la unicidad, requieren la base de datos, pero la mayoría no. Muchas acciones relacionadas con crear / guardar devoluciones de llamada y asociaciones requieren la base de datos, pero otras no. Sé consciente de lo que están haciendo las acciones que estás invocando.

Las pruebas unitarias no deben golpear la base de datos. Deben probar que los métodos se ejecutan como se espera si los datos correctos están disponibles (sin importar de dónde provienen esos datos). Por lo tanto, debe estar pegando / burlándose según sea necesario para asegurarse de que cada prueba de unidad esté aislada.

Sin embargo, las pruebas de integración (como podría escribir con Cucumber , por ejemplo) deberían unir la stack MVC completa, y no hay razón para que no lleguen a la base de datos

El argumento de que es la “forma Rails” de probar los modelos con “pruebas unitarias que llegan a la base de datos” es lo mismo que decir “bueno, todo el mundo salta de un puente, tal vez debería”.

Todas las convenciones de Rails que sigas deben analizarse seriamente, porque en retrospectiva “aplicaciones de Rails monolóticas”, si siguieran este consejo, tendrían más de 100 modelos con pruebas de integración. Incluso si etiquetó las especificaciones con lentitud y rapidez, no tiene pruebas de unidad alrededor de los modelos en la categoría “rápida” (a menos que también las haya escrito, en ese caso, tal vez esté probando demasiado).

Afecto de lado: un conjunto de pruebas de unidad lenta que toma una hora. Y digamos que pegas todos los métodos en tus modelos en lugar de abstraerlos en diferentes clases, estás en un mundo más afectado, porque también necesitas escribir pruebas de integración para ellos.

Sé que no importa lo que hagas, las pruebas de integración seguirán siendo lentas, pero la única forma de combatir la lentitud es escribirlas con inteligencia.

Estoy intentando escribir ‘especificaciones de solicitud’ que golpean la base de datos desde la solicitud HTTP hacia abajo. Y usarlos como mis “pruebas funcionales”. Cada clase que escribo, ya sea un servicio, un modelo o lo que sea que tengas, tiene pruebas de unidad en torno a sus métodos públicos (lo que obviamente apaga el DB).

Utilice una base de datos rápida en la memoria para pruebas de unidad. Si desea probar “los métodos se ejecutan como se espera si los datos correctos están disponibles”, es mejor usar un conjunto de datos que se parezca mucho a su conjunto de datos real. Una base de datos en memoria puede contener conjuntos de datos muy pequeños o bastante grandes, según sus necesidades. HSQLDB es compatible con ruby-on-rails y se usa comúnmente para pruebas unitarias.

    Intereting Posts