¿Qué técnicas se pueden usar para hacer las pruebas de escritura más interesantes?

Question

Debo admitir que a menudo me cuesta practicar el desarrollo basado en pruebas. A pesar de usar Ruby on Rails, lo que hace que TDD sea muy fácil porque está horneado, ¡me parece que las pruebas de escritura son tan aburridas! Es como el uso de hilo dental; Sé que debería hacerlo pero lucho por reunir mucho entusiasmo.

• ¿Qué técnicas usas para hacer que las pruebas de escritura sean interesantes? Por ejemplo, un consejo que vi fue inventar una pequeña historia sobre los datos del accesorio de prueba en lugar de simplemente usar datos sin sentido y sin relación.

Answer 1

Si primero escribe las pruebas, son sus especificaciones para la codificación.

Todo el pensamiento tiene que hacerse al escribir pruebas. "¿Qué debería?" "¿Cómo sabré que lo hizo?" "¿Qué interfaces tiene que se deben burlar?"

Además, si estructura sus pruebas usando una convención de nomenclatura simple (usando "shoulds"), puede determinar más fácilmente lo que se supone que está sucediendo.

Consulte http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx para tener algunas ideas al respecto.

Si escribe las pruebas por última vez, son aburridas, ya que sabe el código funciona.

Answer 2

Si estás aburrido al escribir pruebas, entonces estás probando las cosas incorrectas. Estoy escribiendo pruebas cuando algo falló, cuando no entendí algo o cuando surgió algo nuevo. De esta forma, mis pruebas nunca son inútiles o para cumplir con una política de "cobertura de código 100%" y nunca me aburro.

Answer 3

Escribir pruebas negativas suele ser más interesante que las de "días soleados". Piensa en todas las formas ingeniosas en que podrías romper tu clase (pasar nulo, valores demasiado grandes/pequeños, etc.).

No sólo va a dar a su cerebro un ángulo diferente para masticar también va a hacer su clase más robusto ya que las personas se llamarlo con nulos, grandes números, etc, etc

Answer 4

Primero que quiero escribir código de producción, así que me esfuerzo por escribir primero la prueba: ni escribir ninguna línea de código sin una prueba fallida. Esto no siempre es posible, pero al menos me obliga a escribir pruebas.

entonces intento de romper el código que he escrito usando los límites de test, casos negativos, mal uso de la API (por ejemplo faltantes o varias llamadas de inicialización) ...

también corro el test de frecuencia; el mensaje "todas las pruebas pasadas" al final me hace sentir cómodo con lo que se ha escrito hasta ahora ... y también estoy contento cuando encontré (y solucioné) un error.

A veces, me estoy divirtiendo con los nombres y los números que estoy usando para mis pruebas (fecha de nacimiento, número de jugador favorito, números de teléfono ...).

Answer 5

Si está utilizando TDD correctamente, entonces debe escribir la prueba antes de escribir el código. Debe ser una buena prueba para garantizar que el código que está escribiendo funcione, y debe ser un pequeño incremento.

Como tal, es realmente parte del desarrollo. ¿Qué es diferente de escribir una prueba unitaria vs. escribir una función que necesitas para implementar tu código?

Decir que las pruebas de escritura son aburridas, es como decir "Me resulta muy difícil escribir E/S ... ¿hay algo que pueda hacer para que sea más interesante?" o "Me parece escribir UI aburrido ..."

Bueno, en realidad escribir cualquier tipo de código puede ser aburrido, o interesante ... pero eso es más una función del desarrollador que del código :) Mi amigo está siendo forzado escribir código para una compañía, aunque él no es realmente un programador, y su comentario es "¡¡No veo cómo puedes hacer esto todo el día !!!"

Como desarrollador, creo que le gusta escribir código, por lo que el problema real es que no está siguiendo correctamente TDD y haciendo que las pruebas sean una parte real de su desarrollo. Aunque un marco puede intentar hacer esto necesario, depende de usted seguir correctamente el proceso (es decir, escribir la prueba primero) y realmente integrarlo con su desarrollo.

Entonces, es realmente una parte insignificante del desarrollo general, como el código de entrada, el comentario, el formateo, todo lo cual algunas personas pueden encontrar "aburrido" pero son necesarias. No nos molesta porque es solo parte del desarrollo y nos resulta interesante el desarrollo.

Answer 6

Me preocupa que este suena como un código de olor.

¿Las pruebas son aburridas porque son muy repetitivas?

¿Las pruebas cubren las mismas cosas varias veces? (es decir, los casos de prueba no solo prueban una cosa a la vez, entonces hay muchas pruebas repetidas de las mismas cosas ...?)

Puede estar aburrido porque las pruebas están escritas en el nivel incorrecto de abstracción o te obligan a hacer muchas tareas que no son necesarias.

Parece que algo necesita ser refactorizado o al menos resumido para que cada prueba exprese lo nuevo o diferente del resto del código.

Si muchas pruebas parecen obvias o tediosas, hay algo que falta en las abstracciones que está utilizando.

que había empezar a buscar patrones en los tipos de pruebas que considere aburrido o tedioso yver si hay algo que no se puede hacer - como crear un marco de pruebas pequeña para ayudar a hacer las pruebas más fáciles de escribir.

En el examen, puede que tenga que eliminar algunas pruebas redundantes y limpiar la nomenclatura, para que quede claro exactamente lo que necesita probar y en qué puede confiar para que lo prueben en otro lugar del banco de pruebas.

Esto es todo acerca de las compensaciones. Creo que vale la pena volver a evaluar los tipos de pruebas que está escribiendo y echar un vistazo a las alternativas que podría haber.

Answer 7

Existe la posibilidad de que la aburrición no sea del todo mala. Diría que es más fuerte con respecto a su código regular que a su código de prueba, pero probablemente también se aplique a las pruebas.

La emoción llega cuando no sabes lo que está haciendo tu código, cuando no confías en él, cuando cada vez que lo ejecutas, o lo sueltas, está ese tipo sentado en tu hombro gritando "¡No!" . Cuando pasas mucho tiempo en el depurador; cuando su código es demasiado complejo, enredado y retorcido (no en el buen sentido) y atemorizante.

El aburrimiento puede ser lo opuesto a la emoción, y visto en esa luz, aburrir es bueno. Un pie tras otro, paso predecible después del paso predecible, escribimos un código de trabajo simple y confiable. Red-green-refactor.

El código de trabajo simple y confiable es algo que me entusiasma.