Quiero escribir pruebas para mi aplicación, aunque cada vez que miro rspec.info, realmente no veo una ruta definida para "hacer las cosas bien" y probar primero. Vi los videos de peepcode en rspec más de una vez, pero no es así. Quiero enorgullecerme más de mi trabajo, y creo que las pruebas ayudarán. ¿Cómo puedo romper este bloqueo mental?¿Cómo obtener una actitud mental positiva hacia las pruebas?
Lo odiaba hasta que comencé a crear algunas macros de prueba. Como iniciar sesión o llegar a la página de inicio. Me pareció divertido comenzar a hurgar en lo que realmente podría hacer mi marco de prueba. También ayudó que alguien más me ayudara a escribir algunos. Inmediatamente encontré mejoras obvias que me dieron ganas de entrar y comenzar a mejorar las cosas.
Necesita ver el valor que las pruebas traerán para refactorizar y extender su código. Una vez que tenga un conjunto de pruebas que definen el comportamiento de sus clases, puede comenzar a hacer cambios para mejorar el código. Sus pruebas le darán la confianza de que lo que está haciendo no está rompiendo el sistema. Cuando vaya a agregar una nueva funcionalidad a su código, la ejecución de las pruebas existentes le dará la confianza de que el nuevo código que agregó no interrumpe a ninguna otra cosa.
La clave está en adoptar esa visión a largo plazo. Las pruebas son una inversión. Se aleja un poco del código que podría estar escribiendo, pero finalmente comenzará a pagar con interés. El capital que ha almacenado hará que sea mucho más fácil avanzar más rápido al agregar nuevas características.
Suponiendo que ya tiene una lista de errores que corregir, siempre me gusta volver y, siempre que sea posible, crear una prueba automatizada que demuestre el error. Luego arregla el error y mira pasar la prueba. Ya que tiene que probar el error de todos modos, y el error ya debería darle suficiente información para volver a crearlo, puede ver un retorno inmediato en sus pruebas.
Eventualmente, comenzará a hacerse una idea de cómo armar las pruebas y cómo escribirlas, y no necesitará el "anteproyecto" de un error existente.
Encuentra las herramientas que te recompensarán por probar. Por ejemplo, hacen que sea muy fácil de ejecutar todas las pruebas y obtener un mensaje como
73 tests passed.
Trate random testing porque se puede comprobar con respecto a una gran cantidad de valores de forma rápida y sencilla.
Consulte si su idioma proporciona una herramienta de análisis de cobertura herramienta que le proporciona el porcentaje de cobertura de extracto o porcentaje de cobertura de bloque. Es muy gratificante para impulsar la cobertura de código de 60% hasta 90% --- y si tiene suerte, encontrará errores.
Mi consejo clave es cuantificar su progreso en la prueba para que pueda ver los números que suben. Eso lo hará mucho más motivador. (Vaya, me pregunto qué otros números que se pueden encontrar en este sitio ...)
Piénselo de esta manera: si no prueba, su código está roto.
"Prueba las cosas que no quieres romper".
Puede ser útil establecer prioridades al principio. Sé que escribir las tres capas completas de especificaciones de modelo, vista y controlador sobre las pruebas de aceptación de pepino puede ser una tarea ardua.Así que una idea es simplemente probar las cosas más críticas en su aplicación, y agregar pruebas a medida que se encuentra con errores que no quiere volver a ver.
"Comience siempre con una prueba de falla".
Pepino cuenta con "historias" de texto sin formato que son bastante increíbles para obtener algunas pruebas realmente concretas hasta & ejecutándose. Tal vez ese sería un lugar donde podrías comenzar. Sin embargo, Cucumber realmente no funciona con una aplicación basada en AJAX, para eso tendrías que tomar Selenium o Watir en su lugar. Puede comenzar con una historia que falla antes de escribir una sola línea de código, y proceda rápidamente desde allí para pasar esa historia.
"No realizar la prueba, especifique".
En lugar de pensar en las pruebas, intente hacer un cambio mental: no está probando pero ESPECIFICANDO cómo se comportará su aplicación. Este es un trabajo de diseño, no tan aburrido como las pruebas. :)
¡Bien, te diré cómo!
primero haga el siguiente 10 VECES manualmente en APLICACIONES DIFERENTES, antes de intentar AUTOMATICE
los escenarios negativos, en los que el resultado sería salido negativo. podría ser datos incorrectos ingresados y le da salidas correctas.
por ejemplo una pantalla de inicio de sesión: Podría haber muchos escenarios cuando incorrecto correcto usuario PW, PW correcta incorrecto usuario .... lo más importante es USTED NO DAR, a menos romperlo .Esta es su mantra.
HMMM Ahora ya está pensar como un TESTER ahora a UR SISTEMA, JUS ESCRIBIR los negativos pruebas y sus resultados y les POSITVE LA PRUEBA diseñarlo. AHORA DESARROLLEN EL MARCO
Escribí una publicación de motivación sobre este caso hace un par de días. Aquí está el resumen:
Comience a escribir pruebas cada vez que tenga la oportunidad de hacerlo (es decir, cada vez que se escribe algo de código.). Elija cualquier herramienta que tenga sentido para usted y escribir cualquier prueba que se siente podrían cubrir por lo menos algunos pequeña comportamiento de su aplicación (no se preocupan por la cobertura o cualquier otro término de miedo de el día uno). No tenga miedo de pruebas primitivas y aseveraciones triviales - obtendrá más confianza a medida que su cobertura de prueba crecerá y usted se volverá más y más feliz como lo hará note que no necesita golpear F5 que a menudo nunca más. Piense en pruebas en otros términos positivos - la mejor usted está en él, menos tiempo lo necesario para pasar con actividades que no le gusta (ver el icono de actualización de giro en el navegador, depuración) y mucho más con cosas que amor.
Y aquí está el whole thing, si está interesado.
Como se ha mencionado anteriormente, la manera más fácil de entrar en las pruebas es con las pruebas de regresión.
También evitaría hacer especificaciones del controlador: son un PITA. Haga pruebas de modelos pesadas, porque ahí es donde la lógica debería estar en primer lugar.
Intente especificar/probar un proyecto de rubí simple antes de ir a un proyecto de rieles.
wiki de la comunidad? parece incontestable. –