X
BLOG

¿Están fallando sus pruebas unitarias y no sabe por qué?

¿Están fallando sus pruebas unitarias y no sabe por qué? Tiempo de leer: 5 minutos
De las muchas razones por las que los desarrolladores de software se quejan de las pruebas unitarias, lidiar con suites de pruebas ruidosas es una de las más importantes. Y cuanto más tiempo ha existido una pieza de software, más ruidosa se vuelve.

Para aclarar, por "ruido" me refiero a las pruebas que fallan constantemente, pero sabes (piensas) que está bien de todos modos, así que déjalas estar. O pruebas que a veces fallan y a veces funcionan, pero nadie se ha molestado en averiguarlas o corregirlas. Y luego están las pruebas que están fallando legítimamente porque el código ha cambiado y la prueba debe actualizarse. Todo este ruido está pidiendo a gritos nuestra atención, pero el problema 22 es que cuanto más ruido hay, es menos probable que hagamos algo significativo al respecto.

¿Pero adivina que? En algún lugar de ese ruido de pruebas “fallidas pero correctas” hay algunos problemas reales que desearía conocer. Piense en ello como intentar utilizar un corrector ortográfico. Si no te mantienes al día, obtendrás todo tipo de cosas que no te importan, como palabras especiales de la industria, nombres, etc., que no son problemas reales de ortografía. Pero en algún lugar escondido en ese lío están los errores vergonzosos que realmente cometiste: palabras tontas mal escritas que quieres que salgan de allí. Y por supuesto, hay toneladas de errores ortográficos errantes en todo el mundo - pero a diferencia de su software, no hay muchos riesgos inherentes allí, solo un poco de vergüenza.

Y, sin embargo, los conjuntos de pruebas unitarias se encuentran generalmente en el mismo estado. Muchos resultados ruidosos que nos acostumbramos a ver e ignorar, desafortunadamente esconden resultados reales que necesitamos conocer y comprender. En muchas organizaciones, para resolver esto, alguien programa un sprint para limpiar el conjunto de pruebas de vez en cuando, desde un par de meses hasta incluso un par de años. Se dedica una gran cantidad de tiempo a limpiar la suite lo más humanamente posible, pero, inevitablemente, el problema vuelve de inmediato, y más rápido de lo que cabría esperar. Esto crea un ciclo de retroalimentación negativa: nadie quiere limpiar las pruebas porque cree que volverán a ser ruidosas la próxima vez.

La respuesta es adoptar un enfoque más funcional, uno que elimine los tediosos e inútiles sprints de limpieza y evite los conjuntos de pruebas ruidosos desde el principio.

Minimización de conjuntos de pruebas ruidosos

Para hacerlo, es importante comprender qué significa cuando falla una prueba unitaria. Se reduce a tres razones, con soluciones simples:

  1. El código está roto. Entonces, arregla el código. (Esto es idealmente lo que le dicen las suites de prueba limpias).
  2. El código se cambió correctamente y ahora la prueba no funciona. Por lo tanto, corrija la prueba para que coincida con el nuevo código. (Si su código está cambiando, puede esperar que esto suceda. Una razón importante para trabajar en las pruebas cuando está trabajando en el código).
  3. La prueba es incorrecta y el código está bien. Entonces, arregla la prueba. (O tal vez elimínelo. Pero la clave es: no ignore la prueba).

Ahora. Podrías estar pensando: ¿qué pasa si muchos de mis casos de prueba encajan en esa tercera categoría? ¿Cómo es esto de alguna ayuda? Así que analicemos eso.

Las razones del ruido generalmente se reducen a algunos problemas básicos: pruebas deficientes, pruebas frágiles o afirmaciones deficientes. Las malas pruebas son pruebas que no hacen su trabajo correctamente. O están probando más de lo que deberían o se basan en datos que son inconsistentes o están sujetos a cambios en función de condiciones externas.

Para minimizar el ruido, asegúrese de que para cada prueba que le esté dando problemas (o mejor aún, todas sus pruebas), tenga una buena respuesta a estas dos simples preguntas:

  1. ¿Qué significa si pasa la prueba?
  2. ¿Qué significa si la prueba falla?

Si para alguna prueba no tiene una respuesta razonable a estas dos preguntas, es necesario mejorarla.

Mejora de las pruebas frágiles

Las pruebas frágiles son aquellas que son fáciles de romper. Nuevamente, esto es a menudo un síntoma de afirmaciones perezosas: simplemente verificar las cosas porque se pueden verificar no significa que deban verificarse. Cada afirmación debe tener un significado real en relación con el requisito que cumple el código que se está probando. Los culpables comunes incluyen afirmaciones sensibles a la fecha / hora, dependencias del sistema operativo, dependencias de nombre de archivo / ruta, instalaciones de software de terceros, API de socios, etc. que todo lo que necesita para la prueba es parte de su sistema de compilación y control de código fuente.

Otras malas afirmaciones son aquellas que están constantemente en un estado fallido, pero que no te importa soltarlas de todos modos ("Oh, esas están bien, no te preocupes"), o aquellas que están en un estado en constante cambio (" Antes estaba bien y ayer estaba fallando, ¡¡pero hoy está bien !! ”). Si el código está cambiando, podría estar bien tener resultados que cambien constantemente durante un corto tiempo, pero a largo plazo, debería ser inaceptable. Debe comprender por qué el resultado de la prueba cambia todo el tiempo, o ciertamente por qué cree que está bien fallar y aún así lanzar. Hacer una revisión por pares en sus pruebas unitarias, incluidas las afirmaciones, contribuirá en gran medida a solucionar este problema de forma permanente. (¿Un beneficio adicional de la revisión por pares? Es mucho más fácil sobrevivir si se encuentra en un entorno de cumplimiento donde las pruebas son parte de la supervisión obligatoria).

Evaluar las pruebas rotas es realmente un gran lugar para hacer la mayor parte de su limpieza. Te desafiaría a que mires detenidamente las pruebas que han fallado durante meses o incluso años. Pregúntese si realmente están agregando valor. Recuerde, está ignorando los resultados de todos modos, así que, honestamente, ¿de qué sirven? Eliminar las pruebas que ignora le permitirá concentrarse en las pruebas que importan y, de hecho, mejorará su calidad general.

Y así se vuelve bastante simple (aunque puede llevar una inversión inicial de tiempo). Para limpiar, simplemente observe las siguientes mejores prácticas:

  • Ejecute pruebas con regularidad para que no se desactualicen; trabaje en ellas con el código.
  • Elimine las pruebas que siempre fallan o corríjalas.
  • Elimine las pruebas que cambian constantemente de estado (pasa / falla) o ajústelas.
  • Pruebas unitarias de revisión por pares.

Y, por supuesto, no olvide utilizar la automatización para hacer el trabajo tedioso, de modo que el tiempo que dedica a escribir pruebas sea más productivo, lo que le permitirá crear pruebas que sean menos ruidosas.

Uso de la automatización de pruebas

Aprovechar las pruebas de software automatizadas ayuda a que las tareas de pruebas unitarias sean menos tediosas. Si puedes dejar que la automatización haga las partes simples y tediosas (en las que las computadoras son buenas), te libera para hacer las cosas que requieren inteligencia humana real (en las que eres bueno). Por ejemplo, deje que la automatización cree la primera pasada de trabajo de su xUnidad casos de prueba (código simple que se vuelve muy tedioso de hacer). Si deja que una herramienta genere sus métodos de prueba getter / setter automáticamente, puede ahorrar toneladas de tiempo que puede usar para otras cosas más interesantes.

Cuando nos volvemos más sofisticados con la automatización de pruebas, las herramientas pueden ayudar aún más, haciendo algunas de las partes más complicadas de las pruebas unitarias, como crear y configurar stubs y simulacros. Cuanto más aproveche la automatización, menos tiempo tomará la prueba unitaria, y también será mucho menos aburrido. Si está usando Java, eche un vistazo a nuestro nuevo Asistente de prueba unitaria, integrado en Parasoft Jtest. Hace todas estas cosas y mucho más, lo que hace que las pruebas unitarias no solo sean más fáciles, sino mucho más agradables.

Automatice la creación de pruebas JUnit y comience a amar las pruebas unitarias

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft