test_helper - Ruby on Rails-¿Por qué usar pruebas?
rspec rails (6)
Las pruebas deben validar su lógica de aplicación. Personalmente, creo que mis pruebas más importantes son las que realizo en Selenium. Comprueban que lo que aparece en el navegador es realmente lo que espero ver. Sin embargo, si eso es todo lo que tenía, me resultaría difícil depurarlo: ayuda a tener también pruebas de nivel más bajo y las pruebas de integración, funcionales y unitarias son todas herramientas útiles. Las pruebas unitarias le permiten verificar que el modelo se comporte de la manera que usted espera (y eso significa cada método, no solo validating). Validatins ciertamente solo funcionará, pero solo si lo haces bien. Si los malinterpretas, funcionarán, pero no de la manera que esperabas. Escribir un par de líneas de prueba es más rápido que la depuración más adelante.
Un ejemplo simple como el de http://wiseheartdesign.com/2006/01/16/testing-rails-validations solo comprueba las validaciones en una prueba unitaria. El artículo de O''Reilly en http://www.oreillynet.com/pub/a/ruby/2007/06/07/rails-testing-not-just-for-the-paranoid.html?page=1 es un poco más completo (aunque aún bastante básico).
Las pruebas automáticas son particularmente útiles en las pruebas de regresión, donde usted cambia algo y ejecuta un conjunto de pruebas para verificar que no haya roto nada más.
Las pruebas son una forma de repetición, pero no violan DRY porque expresan las cosas de una manera diferente. Una prueba dice "Hice X así que debería suceder". El código dice "X sucedió, entonces ahora necesito hacer Z, lo que hace que Y suceda". es decir, una prueba estimula una causa y verifica un efecto, mientras que el código responde a una causa y produce un efecto.
Estoy confundido acerca de para qué sirven los diversos dispositivos de prueba en Ruby on Rails. He estado usando el framework por aproximadamente 6 meses pero nunca he entendido la parte de prueba. La única prueba que he usado es JUnit3 en Java y solo brevemente.
Todo lo que he leído al respecto solo muestra las validaciones de prueba. ¿Las validaciones en los rieles no deberían funcionar? Parece más como probar el marco que probar tu código. ¿Por qué necesitarías probar las validaciones?
Además, las pruebas parecen súper frágiles a cualquier cambio en tu código. Entonces, si cambias algo en tus modelos, debes cambiar tus pruebas y accesorios para que coincidan. ¿Esto no viola el principio SECO?
En tercer lugar, escribir código de prueba parece tomar mucho tiempo. ¿Eso es normal? ¿No sería más rápido actualizar mi navegador y ver si funcionaba? Ya tengo que jugar con mi aplicación solo para ver si fluye correctamente y asegurarme de que mi CSS no haya explotado. ¿Por qué las pruebas manuales no serían suficientes?
He hecho estas preguntas antes y no he obtenido más que "las pruebas automatizadas son automáticas". Soy lo suficientemente inteligente como para descubrir las ventajas de automatizar una tarea. Mi problema es que los costos de escribir pruebas parecen absurdamente altos en comparación con los beneficios. Dicho esto, cualquier respuesta detallada es bienvenida porque probablemente me perdí uno o dos beneficios.
Realmente no he usado Rails mucho, pero creo que estas pruebas automatizadas serían útiles como pruebas de humo para asegurarse de que lo que acaba de hacer no rompa algo que hiciste la semana pasada. Esto será cada vez más importante a medida que su proyecto crezca.
Además, escribir las pruebas antes de escribir el código (utilizando el modelo Test-Driven-Development) te ayudará a escribir el código mejor y más rápido, ya que las pruebas te obligan a pensar completamente sobre el problema. También lo ayudará a saber dónde dividir los métodos complejos en métodos más pequeños que pueda probar individualmente.
Tiene razón, escribir y realizar exámenes lleva mucho tiempo. A veces más tiempo que el código en sí. Sin embargo, puede ahorrarle tiempo en la reparación y refactorización de errores por los motivos anteriores.
¿Las validaciones en los rieles no deberían funcionar? Parece más como probar el marco que probar tu código. ¿Por qué necesitarías probar las validaciones?
Las validaciones en Rails funcionan, de hecho, existen pruebas unitarias en la base de código de Rails para garantizarlo. Cuando prueba la validación de un modelo, está probando los detalles de la validación: la longitud, los valores aceptados, etc. Se asegura de que el código se haya escrito como se esperaba. Algunas validaciones son simples ayudantes y puede optar por no probarlas con la idea de que "nadie puede estropear una llamada validates_numericality_of ". ¿Es eso cierto? ¿Todos los desarrolladores siempre recuerdan escribirlo en primer lugar? ¿Cada desarrollador nunca elimina accidentalmente una línea en una copia mal pegada? En mi opinión personal, no es necesario que pruebes hasta la última combinación de valores para un ayudante de validación de Rails, pero necesitas una línea para probar que está ahí con los valores correctos aprobados, en caso de que algún punk lo cambie en el futuro. sin la debida previsión.
Además, otras validaciones son más complejas, requieren mucho código personalizado, pueden garantizar una prueba más exhaustiva.
Además, las pruebas parecen súper frágiles a cualquier cambio en tu código. Entonces, si cambias algo en tus modelos, debes cambiar tus pruebas y accesorios para que coincidan. ¿Esto no viola el principio SECO?
No creo que viole DRY. Se están comunicando (eso es lo que es programación, comunicación) dos cosas muy diferentes. La prueba dice que el código debería hacer algo. El código dice lo que realmente hace. La prueba es extremadamente importante cuando hay una desconexión entre esas cosas.
El código de prueba y el código de la aplicación están íntimamente relacionados, obviamente. Pienso en ellos como dos caras de una moneda. No querrías un frente sin respaldo, o una espalda sin frente. Un buen código de prueba refuerza el buen código de la aplicación, y viceversa. Los dos juntos se utilizan para comprender todo el problema que estás tratando de resolver. Y el código de prueba bien escrito es la documentación: muestra cómo se debe usar el código de la aplicación.
En tercer lugar, escribir código de prueba parece tomar mucho tiempo. ¿Eso es normal? ¿No sería más rápido actualizar mi navegador y ver si funcionaba? Ya tengo que jugar con mi aplicación solo para ver si fluye correctamente y asegurarme de que mi CSS no haya explotado. ¿Por qué las pruebas manuales no serían suficientes?
Usted solo ha trabajado en proyectos muy pequeños, para los cuales esa prueba es discutiblemente suficiente. Sin embargo, cuando trabajas en un proyecto con varios desarrolladores, miles o decenas de miles de líneas de código, puntos de integración con servicios web, bibliotecas de terceros, múltiples bases de datos, meses de desarrollo y cambios de requisitos, etc., hay muchos otros factores en juego. Las pruebas manuales simplemente no son suficientes. En un proyecto de una complejidad real, los cambios en un lugar a menudo pueden tener resultados imprevistos en otros. La arquitectura adecuada ayuda a mitigar este problema, pero las pruebas automatizadas también ayudan (y ayudan a identificar puntos donde la arquitectura se puede mejorar) al identificar cuándo un cambio en un lugar rompe otro.
Mi problema es que los costos de escribir pruebas parecen absurdamente altos en comparación con los beneficios. Dicho esto, cualquier respuesta detallada es bienvenida porque probablemente me perdí uno o dos beneficios.
Enumeraré algunos más beneficios.
Si prueba primero (Desarrollo impulsado por prueba) su código probablemente será mejor. No conocí a un programador que le dio una oportunidad sólida para que este no fuera el caso. Las pruebas primero te obligan a pensar sobre el problema y a diseñar tu solución, en lugar de hackearla. Además, te obliga a comprender el dominio del problema lo suficientemente bien como para que, si tienes que hackearlo, sepas que tu código funciona dentro de las limitaciones que has definido.
Si tiene cobertura de prueba completa, puede refactorizar SIN RIESGO. Si un problema de software es muy complicado (una vez más, los proyectos del mundo real que duran meses tienden a ser complicados), es posible que desee simplificar el código que se ha escrito previamente. Por lo tanto, puede escribir un código nuevo para reemplazar el código anterior, y si pasa todas sus pruebas, ya está. Hace exactamente lo que hizo el código anterior con respecto a las pruebas. Para un proyecto que planea usar un método de desarrollo ágil, la refactorización es absolutamente esencial. Los cambios siempre serán necesarios.
En resumen, las pruebas automatizadas, especialmente el desarrollo basado en pruebas, son básicamente un método para gestionar la complejidad del desarrollo de software. Si su proyecto no es muy complejo, el costo puede superar los beneficios (aunque lo dudo). Sin embargo, los proyectos del mundo real tienden a ser muy complejos, y los resultados de las pruebas y TDD hablan por sí solos: funcionan.
(Si tiene curiosidad, el artículo de Dan North sobre el desarrollo impulsado por el comportamiento es muy útil para comprender gran parte del valor de las pruebas: http://dannorth.net/introducing-bdd )
Todo lo que he leído al respecto solo muestra las validaciones de prueba. ¿Las validaciones en los rieles no deberían funcionar? Parece más como probar el marco que probar tu código. ¿Por qué necesitarías probar las validaciones?
Hay un buen Railscast que muestra una forma de probar los controladores .
Muchos de los tutoriales de prueba y las pruebas de muestra creadas por los generadores de Rails son bastante cojos y en mi humilde opinión pueden dar la impresión errónea de que se supone que debes probar cosas estúpidas como los métodos integrados de Rails, etc.
Dado que Rails tiene su propio conjunto de pruebas, no tiene sentido que escriba o ejecute pruebas que solo prueban integradas en la funcionalidad de Rails. ¡Sus pruebas deben usar el código que está escribiendo! :-)
En cuanto al mérito relativo de ejecutar pruebas frente a la actualización en su navegador ... Cuanto más grande sea su aplicación, más le duele tener que ejecutar manualmente numerosos escenarios y casos extremos para asegurarse de que no haya nada en su aplicación. ha roto. Eventualmente, dejará de probar toda su aplicación después de cada cambio y solo comenzará las "pruebas puntuales" de las áreas que cree que deberían haberse visto afectadas. Inevitablemente, encontrará algo que solía funcionar hace meses que ahora está completamente roto, y no tiene certeza cuando se rompió o qué cambios lo rompieron. Después de que eso suceda lo suficiente ... llegarás a valorar las pruebas automatizadas ... :-)
Por ejemplo: trabajo en un proyecto de más de 25000 líneas (sí, en rails 1.2) y el lunes pasado me dijeron si podía hacer desaparecer a los usuarios de todas las listas, excepto las administrativas, si tenían el atributo "leave_date" establecido en el pasado.
Puede reescribir todas las acciones de la lista (más de 50) para poner una
@ users.reject! {| u | Date.today> u.leave_date}
O puede anular el método "find" (DRY ;-), pero solo si tiene pruebas (¡en todo lo que encuentre usuarios!) Sabrá que no rompió nada anulando User # find !!