En programación informática , la prueba unitaria (o " TU ", o " UT " en inglés) es un procedimiento que permite verificar el correcto funcionamiento de una parte específica de un software o de una parte de un programa (denominada "unidad" o "módulo").
En aplicaciones no críticas, la escritura de pruebas unitarias se ha considerado durante mucho tiempo como una tarea secundaria. Sin embargo, los métodos Extreme Programming (XP) o Test Driven Development (TDD) han vuelto a colocar las pruebas unitarias, conocidas como “pruebas de programador”, en el centro de la actividad de programación.
El entorno de prueba SUnit para el lenguaje Smalltalk , creado enOctubre de 1994por Kent Beck . En 1997, Kent Beck conoció a Erich Gamma con quien creó JUnit que, por su popularidad, llevó a la creación de muchos frameworks de pruebas unitarias, este conjunto se llama xUnit .
Al mismo tiempo, se desarrolló la prueba ATTOL Unit, que luego fue utilizada por Sextant Avionique en 1998
Escribimos una prueba para comparar una realización con su especificación. La prueba define un criterio de parada (estado o salidas al final de la ejecución) y permite dictaminar sobre el éxito o el fracaso de una verificación. Gracias a la especificación, uno puede hacer coincidir un estado de entrada dado con un resultado o una salida. La prueba permite verificar que efectivamente se lleva a cabo la relación entrada / salida dada por la especificación.
El método XP recomienda escribir las pruebas al mismo tiempo, o incluso antes de la función que se va a probar ( Test Driven Development ). Esto permite definir con precisión la interfaz del módulo a desarrollar. Las pruebas se ejecutan durante todo el desarrollo, lo que permite ver si el código recién escrito coincide con el requisito.
Cuando se modifica un programa, las pruebas unitarias informan de cualquier regresión . De hecho, algunas pruebas pueden fallar después de una modificación, por lo que es necesario reescribir la prueba para que corresponda a las nuevas expectativas o corregir el error en el código.
Las pruebas unitarias se pueden usar como complemento a la API , es muy útil leer las pruebas para comprender cómo se usa un método. Además, es posible que la documentación ya no esté actualizada, pero las pruebas en sí se correspondan con la realidad de la aplicación.
Generalmente definimos 4 fases en la ejecución de una prueba unitaria:
Esto es para que el programador pruebe un módulo , independientemente del resto del programa, para asegurarse de que cumple con las especificaciones funcionales y que funciona correctamente en todas las circunstancias. Esta verificación se considera esencial, especialmente en aplicaciones críticas. Elle s'accompagne couramment d'une vérification de la couverture de code (évaluation de la couverture structurelle), qui consiste à s'assurer que l'ensemble des tests conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans el código.
Todas las pruebas unitarias deben reproducirse después de una modificación del código para comprobar que no hay regresiones (aparición de nuevas disfunciones). El uso de una "estrategia de prueba" particular puede limitar las pruebas que se reproducirán, por ejemplo: un análisis de impacto de las modificaciones, correlacionado con una prueba de independencia de los módulos, permite apuntar a los casos de prueba unitarios que se reproducirán.
Una prueba debe corresponder a las especificaciones de la aplicación, por lo que debes escribir las pruebas primero y luego aprobarlas más tarde en lugar de escribir el código antes y correr el riesgo de ser influenciado por él durante las pruebas de escritura. Bob Martin, gran defensor del método TDD , ofrece un modelo simple para escribir pruebas unitarias:
Los simulacros son objetos para simular un objeto real de una manera controlada. En algunos casos, el uso de simulacros es esencial para ahorrar tiempo de cobertura del código y probar la confiabilidad.
Sin embargo, el uso indebido de simulacros puede tener el efecto contrario, incluido el aumento del tiempo de ejecución de la prueba, lo que hace que las pruebas sean complicadas de entender.
La mayoría de los frameworks de la familia xUnit permiten la generación de clases de prueba unitaria. Sin embargo, estos marcos solo proporcionan el esqueleto de las clases. Por lo tanto, las pruebas deberán ser escritas por el desarrollador.
La generación de pruebas unitarias es un tema importante para los investigadores y varios congresos están interesados en este tema, como el Simposio Internacional de Pruebas y Análisis de Software (ISSTA), el Congreso Internacional de Ingeniería de Software (ICSE) y la Ingeniería de Software Automatizada (ASE).
Al modificar el código de un programa, es posible que algunas pruebas ya no pasen; en este caso, el desarrollador debe determinar si proviene del propio código o de la prueba: si proviene de la prueba, el desarrollador debe modificar su prueba porque eliminarla aumentaría las posibilidades de regresión del programa. Algunos investigadores han desarrollado herramientas para solucionar este problema.
ReAssert es una herramienta que sugiere reparaciones para una prueba fallida, analiza las pruebas para su modificación y sugiere cambios al desarrollador, si la sugerencia le conviene al desarrollador, puede hacer el cambio con el clic de un botón.
Las pruebas unitarias parametrizables son pruebas unitarias que toman parámetros. Luego pueden usar herramientas como QuickCheck para generar parámetros. Estas pruebas son compatibles con JUnit , TestNG y NUnit.
Al confiar en casos concretos de entrada y salida, la generación de Oracle y la cobertura de prueba para minimizar los casos, los investigadores han logrado generar pruebas unitarias configurables. Los resultados de este método son prometedores.
Hay una multitud de Toolkits ( framework ) para realizar fácilmente pruebas unitarias. Existen en los principales lenguajes de programación . Por ejemplo Test::More para Perl .
El término genérico “ xUnit ” designa una herramienta que permite realizar pruebas unitarias en un idioma determinado (la inicial de la cual generalmente reemplaza a la “x”).
Varias herramientas permiten la automatización de pruebas unitarias: