it-swarm-es.com

¿Cómo ha logrado que las pruebas unitarias sean más agradables?

Si siempre te han gustado las pruebas unitarias, ¡bien por ti! Pero para los desafortunados que no nacieron con gusto por ello, ¿cómo han logrado hacer más placentera esta tarea?

Esta no es una pregunta sobre "cuál es la forma correcta de realizar una prueba unitaria". Simplemente quiero conocer pequeños trucos personales que reduzcan el aburrimiento (me atrevo a decir) de escribir pruebas unitarias.

18
Preets

En primer lugar, estoy de acuerdo con usted: si está escribiendo sus pruebas unitarias en un código ya completado, o si está probando manualmente su código unitario, eso también me parece extremadamente aburrido.

Creo que hay dos formas de realizar pruebas unitarias para mí que realmente lo hacen agradable:

  1. Al usar Test Driven Development (TDD), escribir las pruebas primero me permite pensar en la siguiente parte de funcionalidad o comportamiento que necesito en mi código. Me parece que conducir hacia mi objetivo final en pequeños pasos y ver un progreso tangible hacia ese objetivo cada pocos minutos es extremadamente gratificante y agradable.
  2. Cuando hay errores, en lugar de ir directamente al depurador, es un desafío divertido encontrar una manera de escribir una prueba de unidad fallida que reproduzca el error. Es extremadamente satisfactorio descubrir finalmente las circunstancias que hacen que su código falle, luego corregirlo y ver cómo la barra se vuelve verde para la nueva prueba fallida (y permanece verde para todas sus pruebas existentes).
22
Paddyslacker

Superioridad presumida.

Solo bromeo a medias. "¡Mírame, cultivando buenos hábitos de programación! Este tema de las 'pruebas unitarias' es algo que Yo, de hace diez años, nunca hubiera hecho, ¡qué tonto! Y solo piensa en todos los errores que voy a detectar como resultado de este trabajo aburrido y tedioso que estoy haciendo ahora mismo. ¡Mi código será increíble! ¡Seguro que obtendré un aumento! * "

* - No, no lo haré.

Encuentro que es como hacer ejercicio o comer sano; hasta que los beneficios tangibles realmente entren en acción ("¡Dios mío, realmente estoy atrapando una tonelada de errores de regresión que se habrían colado en la producción!"), el orgullo moral de saber que estás haciendo lo correcto puede ayudarte mediante.

12
BlairHippo

Por un lado, casi nunca me siento ahí y escribo pruebas unitarias. Las pruebas unitarias son un medio para un fin, no un fin en sí mismas. Son una forma de responder "este código hace la tarea básica que se supone que debe hacer".

Por ejemplo, algunas personas escribirán una función y luego abrirán una sesión interactiva para probarla en algunos valores y asegurarse de que esté funcionando:

def fact x
  if x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact 10
=> 3628800
>> fact 7
=> 5040

Pero ahora descubres un error:

>> fact -1
SystemStackError: stack level too deep
    from (irb):2:in `fact'
    from (irb):5:in `fact'
    from (irb):10

Entonces lo arreglas:

def fact x
  if x < 0
    raise "Can't take the factorial of a negative number"
  elsif x == 0
    1
  else 
    x * fact(x-1)
  end
end

>> fact -1
RuntimeError: Can't take the factorial of a negative number
    from (irb):3:in `fact'
    from (irb):10

Pero ahora realmente debería probar para asegurarse de que todavía funciona:

>> fact 10
=> 3628800
>> fact 7
=> 5040

Como ves, sigues repitiendo las mismas pruebas ... y tienes que comparar visualmente los resultados. La prueba unitaria es una forma de evitar la repetición en este caso; reduce la cantidad de trabajo que necesita hacer. Y aunque este es un pequeño ejemplo tonto, en el mundo real, se vuelve cada vez más importante y cada vez más difícil de probar manualmente. Lo que esto significa, por supuesto, es que la gente simplemente no prueba los componentes individuales; simplemente prueban todo el programa. Pero luego surgen errores y son mucho más difíciles de encontrar. O suceden errores y se corrigen, pero alguien introduce el mismo error de nuevo, porque nadie agregó un caso de prueba para asegurarse de que eso no sucedió. O alguien mira un gran fragmento de código y dice "No tengo idea de lo que se supone que debe hacer, ya que no está documentado y no tiene pruebas ... si soluciono este error, no tengo idea de si fallaré algo más dependiendo de ello; tal vez simplemente vuelva a escribir esto desde cero ".

Las pruebas unitarias reducen todo el trabajo adicional en estos casos. La mejor manera de hacerlos divertidos es asegurarse de que las personas comprendan todo el trabajo que están reemplazando y la flexibilidad adicional que se obtiene al saber lo que se supone que debe hacer cada fragmento de código. Hasta cierto punto, las personas necesitan tener un poco más de experiencia escribiendo y manteniendo una gran base de código para comprender lo importante que pueden ser las pruebas unitarias; si todo su código es algo que escriben una vez y desechan, nunca lo conseguirán.

Y las pruebas unitarias no deben escribirse después del hecho, como una tarea adicional una vez que tenga el código que "sabe" que ya funciona. Las pruebas unitarias deben escribirse primero, o al menos (ya que a veces te olvidas de escribirlas primero) justo después de escribir el código en cuestión. A esto se le llama desarrollo basado en pruebas y puede ayudar a mejorar sus API; Si escribe las pruebas que ejercitan las API primero, aprenderá dónde es difícil usar las API antes de escribir el código, y podrá rediseñar mucho más fácilmente que si solo agrega las pruebas después.

7
Brian Campbell

No lo sé. Lo que definitivamente hace que las pruebas unitarias sean más agradables para mí es la idea de toda la depuración frustrante, prolongada, aburrida e ingrata que no tendré que realizar cada vez que haga un cambio en el software :)

5
back2dos

Obviamente, existe la satisfacción del desarrollo de la prueba primero y la sensación que se obtiene cuando el diseño y las pruebas se unen. Sin embargo, escribir pruebas para código preexistente/heredado puede ser abrumador y frustrante. Cuando nuestro proyecto estaba en un patrón de mantenimiento, escribí pruebas para código no probado usando el informe de cobertura como un juego. Puede crear una pequeña competencia con usted mismo y/o con otros para aumentar los números de cobertura. Por supuesto, es posible que lo lleve demasiado lejos y cree algunas pruebas malas, pero puede ser un buen motivador.

3
Matt H

La superioridad presumida que sientes cuando verificas un código sólido, robusto y estable. Y si escribe pruebas unitarias con una herramienta de cobertura de código, puede presumir en sus comentarios de verificación de que la cobertura de su código es del 90% o más.

3
C Johnson

Intenta entrar en Flow . Fíjese metas difíciles pero alcanzables. ¿Cuál podría ser un objetivo en las pruebas unitarias? Por ejemplo, intente escribir más rápido manteniendo la calidad. Las pruebas unitarias no requieren demasiada reflexión, por lo que es poco probable que se confundan. Concéntrese en su objetivo y verifique con frecuencia para ver a medida que se acerca a él.

1
Tamás Szelei

Al no intentar engañarme a mí mismo, puedo engañar a mi mente para que piense que las pruebas unitarias pueden ser agradables durante cualquier período de tiempo sostenible.

Aceptar la realidad de que las pruebas unitarias no están para disfrutarlas me ayuda mucho, haciéndome dar cuenta de que estoy buscando algo en un lugar donde nunca se suponía que debía estar.

En estas breves excursiones mentales, cuando llego al punto de percibir que las pruebas unitarias son lo que realmente son, es decir, una tarea cruel, insoportable y abrumadora, me pregunto si puedo permitirme el lujo de dejarlas ir, es decir, no tener altas garantías de corrección funcional.

Invariablemente, la respuesta es un rotundo "no".

Al aceptar mi destino, sigo empujando estos objetos cuadrados con letras, números y símbolos frente a mí, lo que llamamos teclado, sabiendo por experiencia propia que con cada clic del teclado, el final de la prueba unitaria está más cerca que ha alguna vez ha sido.

0
bugfoot

A veces, para motivarme, escribo mi "cobertura de código" actual al comienzo del día. Luego, cada vez que escribo una prueba y la apruebo, ejecutaré la suite y actualizaré el número de cobertura. Es divertido y me ayuda a recordar por qué estoy haciendo esto. (También hay otras razones, pero me gustan los números. ¡Quizás sea solo yo!)

0
Marcie