2012-04-02 27 views
5

En los últimos días he progresado lentamente añadiendo pruebas a una aplicación de rieles existente en la que he estado trabajando durante un tiempo.¿Cómo debo probar mi aplicación Rails?

Estoy tratando de averiguar cuánto y qué tipo de pruebas (unidad, funcional, integración) serán suficientes para ahorrarme tiempo de depuración y reparación de implementaciones que rompen la funcionalidad existente.

Soy el único que trabaja en esta aplicación. Básicamente es una base de datos de gestión de inventario para una empresa pequeña (~ 20 empleados). No agregué pruebas desde el principio porque realmente no entendí el punto, pero tengo un par de implementaciones que han estropeado la funcionalidad existente en el último momento, así que pensé que sería una buena idea agregar.

¿Debo probar mis modelos y controladores individualmente Y realizar pruebas de integración? Parece que hay desarrolladores que creen que solo debes probar la integración y retroceder para descubrir qué ocurre si recibes un error.

Hasta ahora estoy usando RSpec + Factory Girl + Shoulda. Eso hizo que sea bastante fácil configurar pruebas para los modelos.

Estoy empezando con los controladores ahora y estoy más que un poco perdido. Sé cómo probar un controlador individual, pero no sé si debería probar el flujo de aplicaciones usando pruebas de integración, ya que eso probaría los controladores al mismo tiempo.

+0

Bienvenido a la parte positiva :) –

Respuesta

1

Escribir pruebas después de que la aplicación ya está escrita va a ser tedioso. Como mínimo, debe probar los casos de integración (que probarán la mayoría de las funciones y vistas del controlador), y también modelar las pruebas por separado para que las llamadas a modelo funcionen como usted cree que deberían.

Para pruebas de integración, encuentro Capybara fácil de usar.

3

Uso las pruebas de integración para probar las rutas exitosas y las rutas de fallas generales, pero para los casos de borde o escenarios más profundos entonces escribo las pruebas de modelo/vista/controlador.

Normalmente escribo las pruebas antes de escribir la funcionalidad en la aplicación, pero si desea agregar pruebas luego, recomiendo usar algo como SimpleCov para ver qué áreas de su aplicación necesitan más pruebas y acumular lentamente la cobertura de prueba para su solicitud.

+0

+1 por mencionar la cobertura. –

0

Como regla general, la mayoría de sus pruebas deben ser unidad, algunas funcional, poca integración.

Rails se adhiere a esto de todo corazón y usted debe hacer lo mismo.

Como mínimo hay que tener:

  • una prueba de unidad para cada uno de sus modelos, añadir un caso de prueba para cada uno de sus validaciones en cada uno de ellos, y finalmente una última para hacer seguro de que el modelo está guardado Si tiene cosas como dependant: :destroy, touch: true en modelos relacionados (has_many, belongs_to), agregue casos de prueba para ellos también.
  • A prueba funcional para cada uno de sus controladores. Casos de prueba para cada acción. Algunas acciones pueden tener respuestas múltiples (como en el caso de errores 422), así que agregue otro caso para probar la respuesta de error. Si tiene un filtro de autorización, pruébelos también.

Luego puede realizar una prueba de integración para un nuevo flujo de usuario típico. Me gusta Regístrese -> Crear mensaje -> Verlo -> cerrar sesión. Otra es asegurarse de que los usuarios no autorizados no puedan acceder a sus recursos.

Y a partir de ahora, no confíe CUALQUIER código sin las pruebas mencionadas anteriormente.

El mejor momento para plantar un árbol fue hace 10 años, el segundo mejor momento ahora es, ¡así que empiece a probar!

Cuestiones relacionadas