En programación de computadoras , las pruebas unitarias son un método de prueba de software mediante el cual unidades individuales de código fuente (conjuntos de uno o más módulos de programas de computadora junto con datos de control, procedimientos de uso y procedimientos operativos asociados) se prueban para determinar si son aptos para su uso. . [1] Es un paso estándar en enfoques de desarrollo e implementación como Agile .
Antes de las pruebas unitarias, las herramientas de prueba de captura y reproducción eran la norma. En 1997, Kent Beck y Erich Gamma desarrollaron y lanzaron JUnit , un marco de prueba unitario que se hizo popular entre los desarrolladores de Java . [2] Google adoptó las pruebas automatizadas alrededor de 2005-2006. [3]
La unidad sería el componente más pequeño que se puede aislar dentro de la compleja estructura de una aplicación. [4] Podría ser una función, una subrutina, un método o propiedad.
Las pruebas unitarias son pruebas automatizadas o pruebas manuales, escritas y ejecutadas por desarrolladores de software para garantizar que una sección de una aplicación (conocida como "unidad") cumpla con su diseño y se comporte según lo previsto. [5] A menudo los realiza el desarrollador que escribió originalmente el código, como primera línea de defensa antes de realizar más pruebas.
En programación de procedimientos , una unidad podría ser un módulo completo, pero más comúnmente es una función o procedimiento individual.
En la programación orientada a objetos , una unidad suele ser una interfaz completa, como una clase o un método individual. [6] Al escribir pruebas primero para las unidades comprobables más pequeñas y luego los comportamientos compuestos entre ellas, se pueden crear pruebas integrales para aplicaciones complejas. [5]
Durante el desarrollo, un desarrollador de software puede codificar criterios o resultados que se sabe que son buenos en la prueba para verificar la corrección de la unidad. Durante la ejecución del caso de prueba, los marcos registran las pruebas que no cumplen con algún criterio y las informan en un resumen. Para ello, el enfoque más utilizado es prueba - función - valor esperado.
Para aislar los problemas que puedan surgir, cada caso de prueba debe probarse de forma independiente. Se pueden utilizar sustitutos como códigos auxiliares de métodos , objetos simulados , [7] falsificaciones y arneses de prueba para ayudar a probar un módulo de forma aislada.
Las pruebas parametrizadas son una técnica que pretende acortar el proceso de redacción y mantenimiento de pruebas unitarias. Las pruebas parametrizadas permiten la ejecución de una prueba varias veces con diferentes conjuntos de entradas, lo que reduce la duplicación del código de prueba. A diferencia de las pruebas unitarias tradicionales, que suelen ser métodos cerrados y prueban condiciones invariantes, las pruebas parametrizadas toman cualquier conjunto de parámetros. Las pruebas parametrizadas son compatibles con TestNG , JUnit [8] y sus homólogos .Net, XUnit y NUnit , así como en varios marcos de prueba de JavaScript. [ cita necesaria ]
Los parámetros adecuados para las pruebas unitarias se pueden proporcionar manualmente o, en algunos casos, el marco de pruebas los genera automáticamente. En los últimos años se agregó soporte para escribir pruebas (unitarias) más poderosas, aprovechando el concepto de teorías, casos de prueba que ejecutan los mismos pasos, pero usando datos de prueba generados en tiempo de ejecución, a diferencia de las pruebas parametrizadas regulares que usan los mismos pasos de ejecución con conjuntos de entrada. que están predefinidos. [ cita necesaria ]
En el proceso de desarrollo ágil, las pruebas unitarias se realizan por historia de usuario y se realizan en la segunda mitad del sprint, una vez que se completan la recopilación de requisitos y el desarrollo. Normalmente, los desarrolladores u otros miembros del equipo de desarrollo, como consultores , escribirán 'scripts de prueba' paso a paso para que los desarrolladores los ejecuten en la herramienta. Los scripts de prueba generalmente se escriben para demostrar el funcionamiento técnico y efectivo de funciones desarrolladas específicas en la herramienta, a diferencia de los procesos comerciales completos que serían interconectados por el usuario final , lo que generalmente se realiza durante las pruebas de aceptación del usuario . Si el script de prueba se puede ejecutar completamente de principio a fin sin incidentes, se considera que la prueba unitaria ha "aprobado"; de lo contrario, se anotan errores y la historia del usuario vuelve a estar en desarrollo en un estado "en progreso". Las historias de usuarios que pasan con éxito las pruebas unitarias pasan a los pasos finales del sprint: revisión del código, revisión por pares y, por último, una sesión de presentación que demuestra la herramienta desarrollada a las partes interesadas.
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. [1] Una prueba unitaria proporciona un contrato escrito estricto que el fragmento de código debe cumplir. Como resultado, ofrece varios beneficios.
Las pruebas unitarias encuentran problemas en las primeras etapas del ciclo de desarrollo . Esto incluye tanto errores en la implementación del programador como fallas o partes faltantes de la especificación de la unidad. El proceso de escribir un conjunto completo de pruebas obliga al autor a pensar en las entradas, salidas y condiciones de error y, por lo tanto, definir de manera más clara el comportamiento deseado de la unidad. [ cita necesaria ]
El costo de encontrar un error antes de que comience la codificación o cuando el código se escribe por primera vez es considerablemente menor que el costo de detectar, identificar y corregir el error más adelante. Los errores en el código publicado también pueden causar problemas costosos para los usuarios finales del software. [9] [10] [11] El código puede ser imposible o difícil de probar unitariamente si está mal escrito, por lo que las pruebas unitarias pueden obligar a los desarrolladores a estructurar funciones y objetos de mejores maneras.
En el desarrollo basado en pruebas (TDD), que se utiliza con frecuencia tanto en programación extrema como en scrum , las pruebas unitarias se crean antes de escribir el código. Cuando pasan las pruebas, ese código se considera completo. Las mismas pruebas unitarias se ejecutan con frecuencia en esa función a medida que se desarrolla la base de código más grande, ya sea cuando se cambia el código o mediante un proceso automatizado con la compilación. Si las pruebas unitarias fallan, se considera un error en el código modificado o en las pruebas mismas. Las pruebas unitarias permiten entonces rastrear fácilmente la ubicación de la falla o falla. Dado que las pruebas unitarias alertan al equipo de desarrollo del problema antes de entregar el código a los evaluadores o clientes, los problemas potenciales se detectan en las primeras etapas del proceso de desarrollo.
Las pruebas unitarias permiten lanzamientos más frecuentes en el desarrollo de software. Al probar componentes individuales de forma aislada, los desarrolladores pueden identificar y abordar problemas rápidamente, lo que lleva a ciclos de iteración y lanzamiento más rápidos. [12]
Las pruebas unitarias permiten al programador refactorizar el código o actualizar las bibliotecas del sistema en una fecha posterior y asegurarse de que el módulo aún funcione correctamente (por ejemplo, en pruebas de regresión ). El procedimiento consiste en escribir casos de prueba para todas las funciones y métodos de modo que cada vez que un cambio cause una falla, se pueda identificar rápidamente.
Las pruebas unitarias detectan cambios que pueden romper un contrato de diseño .
Las pruebas unitarias pueden reducir la incertidumbre en las propias unidades y pueden usarse en un enfoque de estilo de prueba ascendente . Al probar primero las partes de un programa y luego probar la suma de sus partes, las pruebas de integración se vuelven mucho más fáciles. [ cita necesaria ]
Las pruebas unitarias proporcionan una especie de documentación viva del sistema. Los desarrolladores que quieran aprender qué funcionalidad proporciona una unidad y cómo usarla, pueden consultar las pruebas unitarias para obtener una comprensión básica de la interfaz de la unidad ( API ). [ cita necesaria ]
Los casos de prueba unitarios incorporan características que son críticas para el éxito de la unidad. Estas características pueden indicar el uso apropiado/inapropiado de una unidad, así como comportamientos negativos que la unidad debe atrapar. Un caso de prueba unitaria, en sí mismo, documenta estas características críticas, aunque muchos entornos de desarrollo de software no dependen únicamente del código para documentar el producto en desarrollo. [ cita necesaria ]
Cuando el software se desarrolla utilizando un enfoque basado en pruebas, la combinación de escribir la prueba unitaria para especificar la interfaz más las actividades de refactorización realizadas después de que la prueba haya pasado, puede reemplazar el diseño formal. Cada prueba unitaria puede verse como un elemento de diseño que especifica clases, métodos y comportamiento observable. [ cita necesaria ]
Las pruebas no detectarán todos los errores del programa, porque no pueden evaluar todas las rutas de ejecución excepto en los programas más triviales. Este problema es un superconjunto del problema de la detención , que es indecidible . Lo mismo ocurre con las pruebas unitarias. Además, las pruebas unitarias, por definición, solo prueban la funcionalidad de las propias unidades. Por lo tanto, no detectará errores de integración ni errores más amplios a nivel del sistema (como funciones realizadas en varias unidades o áreas de prueba no funcionales como el rendimiento ). Las pruebas unitarias deben realizarse junto con otras actividades de prueba de software , ya que sólo pueden mostrar la presencia o ausencia de errores particulares; no pueden probar una ausencia total de errores. Para garantizar el comportamiento correcto de cada ruta de ejecución y cada entrada posible, y asegurar la ausencia de errores, se requieren otras técnicas, concretamente la aplicación de métodos formales para demostrar que un componente de software no tiene un comportamiento inesperado. [ cita necesaria ]
Una jerarquía elaborada de pruebas unitarias no equivale a pruebas de integración. La integración con unidades periféricas debe incluirse en las pruebas de integración, pero no en las pruebas unitarias. [ cita requerida ] Las pruebas de integración normalmente todavía dependen en gran medida de las pruebas realizadas manualmente por humanos ; Las pruebas de alto nivel o de alcance global pueden ser difíciles de automatizar, de modo que las pruebas manuales a menudo parecen más rápidas y económicas. [ cita necesaria ]
Las pruebas de software son un problema combinatorio. Por ejemplo, cada declaración de decisión booleana requiere al menos dos pruebas: una con un resultado "verdadero" y otra con un resultado "falso". Como resultado, por cada línea de código escrita, los programadores suelen necesitar de 3 a 5 líneas de código de prueba. [ cita necesaria ] Esto obviamente lleva tiempo y es posible que su inversión no valga la pena. Hay problemas que no se pueden probar fácilmente, por ejemplo, aquellos que no son deterministas o involucran múltiples subprocesos . Además, es tan probable que el código para una prueba unitaria tenga errores como el código que se está probando. Fred Brooks en The Mythical Man-Month cita: "Nunca te hagas a la mar con dos cronómetros; lleva uno o tres". [13] Es decir, si dos cronómetros se contradicen, ¿cómo se sabe cuál es el correcto?
Otro desafío relacionado con la redacción de pruebas unitarias es la dificultad de configurar pruebas realistas y útiles. Es necesario crear condiciones iniciales relevantes para que la parte de la aplicación que se está probando se comporte como parte del sistema completo. Si estas condiciones iniciales no se establecen correctamente, la prueba no ejercitará el código en un contexto realista, lo que disminuye el valor y la precisión de los resultados de las pruebas unitarias. [ cita necesaria ]
Para obtener los beneficios previstos de las pruebas unitarias, se necesita una disciplina rigurosa durante todo el proceso de desarrollo de software.
Es fundamental mantener registros cuidadosos no sólo de las pruebas que se han realizado, sino también de todos los cambios que se han realizado en el código fuente de esta o cualquier otra unidad del software. Es imprescindible el uso de un sistema de control de versiones . Si una versión posterior de la unidad no pasa una prueba particular que había pasado previamente, el software de control de versiones puede proporcionar una lista de los cambios en el código fuente (si los hay) que se han aplicado a la unidad desde ese momento. [ cita necesaria ]
También es esencial implementar un proceso sostenible para garantizar que las fallas de los casos de prueba se revisen periódicamente y se aborden de inmediato. [14] Si dicho proceso no se implementa y no se integra en el flujo de trabajo del equipo, la aplicación no estará sincronizada con el conjunto de pruebas unitarias, lo que aumentará los falsos positivos y reducirá la eficacia del conjunto de pruebas.
Las pruebas unitarias del software del sistema integrado presentan un desafío único: debido a que el software se desarrolla en una plataforma diferente a la que finalmente se ejecutará, no es posible ejecutar fácilmente un programa de prueba en el entorno de implementación real, como es posible con los programas de escritorio. [15]
Las pruebas unitarias tienden a ser más sencillas cuando un método tiene parámetros de entrada y algo de salida. No es tan fácil crear pruebas unitarias cuando una función principal del método es interactuar con algo externo a la aplicación. Por ejemplo, un método que funcione con una base de datos podría requerir la creación de una maqueta de las interacciones de la base de datos, que probablemente no será tan completa como las interacciones reales de la base de datos. [16] [ se necesita una mejor fuente ]
A continuación se muestra un conjunto de casos de prueba en Java que especifican una serie de elementos de la implementación. Primero, debe haber una interfaz llamada Adder y una clase de implementación con un constructor sin argumentos llamado AdderImpl. Continúa afirmando que la interfaz Adder debería tener un método llamado agregar, con dos parámetros enteros, que devuelve otro número entero. También especifica el comportamiento de este método para un pequeño rango de valores en varios métodos de prueba.
importar org.junit.Assert.assertEquals estático ; importar org.junit.Test ; clase pública TestAdder { // ¿puede sumar los números positivos 1 y 1? @Test public void testSumPositiveNumbersOneAndOne () { Adder sumador = new AdderImpl (); afirmarEquals ( 2 , sumador . agregar ( 1 , 1 )); } // ¿puede sumar los números positivos 1 y 2? @Test public void testSumPositiveNumbersOneAndTwo () { Adder sumador = new AdderImpl (); afirmarEquals ( 3 , sumador . agregar ( 1 , 2 )); } // ¿puede sumar los números positivos 2 y 2? @Test public void testSumPositiveNumbersTwoAndTwo () { Adder sumador = new AdderImpl (); afirmarEquals ( 4 , sumador . agregar ( 2 , 2 )); } // ¿el cero es neutral? @Test public void testSumZeroNeutral () { Adder sumador = new AdderImpl (); afirmarEquals ( 0 , sumador . agregar ( 0 , 0 )); } // ¿Puede sumar los números negativos -1 y -2? @Test public void testSumNegativeNumbers () { Adder sumador = new AdderImpl (); afirmarEquals ( - 3 , sumador . agregar ( - 1 , - 2 )); } // ¿puede agregar un positivo y un negativo? @Test public void testSumPositiveAndNegative () { Adder sumador = new AdderImpl (); afirmarEquals ( 0 , sumador . agregar ( - 1 , 1 )); } // ¿Qué tal números más grandes? @Test public void testSumLargeNumbers () { Adder sumador = new AdderImpl (); afirmarEquals ( 2222 , sumador . agregar ( 1234 , 988 )); } } En este caso, las pruebas unitarias, una vez escritas primero, actúan como un documento de diseño que especifica la forma y el comportamiento de una solución deseada, pero no los detalles de implementación, que quedan en manos del programador. Siguiendo la práctica de "hacer lo más simple que pueda funcionar", a continuación se muestra la solución más sencilla que permitirá pasar la prueba.
sumador de interfaz { int add ( int a , int b ); } clase AdderImpl implementa Adder { public int add ( int a , int b ) { return a + b ; } } El uso de pruebas unitarias como especificación de diseño tiene una ventaja significativa sobre otros métodos de diseño: el documento de diseño (las propias pruebas unitarias) se puede utilizar para verificar la implementación. Las pruebas nunca pasarán a menos que el desarrollador implemente una solución acorde al diseño.
Las pruebas unitarias carecen de algo de la accesibilidad de una especificación esquemática como un diagrama UML , pero pueden generarse a partir de la prueba unitaria utilizando herramientas automatizadas. La mayoría de los lenguajes modernos tienen herramientas gratuitas (normalmente disponibles como extensiones de los IDE ). Las herramientas gratuitas, como las basadas en el marco xUnit , subcontratan a otro sistema la representación gráfica de una vista para consumo humano.
Las pruebas unitarias son la piedra angular de la programación extrema , que se basa en un marco de pruebas unitarias automatizadas . Este marco de pruebas unitarias automatizadas puede ser de un tercero, por ejemplo, xUnit , o creado dentro del grupo de desarrollo.
La programación extrema utiliza la creación de pruebas unitarias para el desarrollo basado en pruebas . El desarrollador escribe una prueba unitaria que expone un requisito de software o un defecto. Esta prueba fallará porque el requisito aún no se implementó o porque expone intencionalmente un defecto en el código existente. Luego, el desarrollador escribe el código más simple para que la prueba, junto con otras pruebas, pase.
La mayor parte del código de un sistema se prueba unitariamente, pero no necesariamente todas las rutas a través del código. La programación extrema exige una estrategia de "probar todo lo que pueda fallar", en lugar del método tradicional de "probar cada ruta de ejecución". Esto lleva a los desarrolladores a desarrollar menos pruebas que los métodos clásicos, pero esto no es realmente un problema, sino más bien una reafirmación de un hecho, ya que los métodos clásicos rara vez se han seguido lo suficientemente metódicamente como para que todas las rutas de ejecución hayan sido probadas exhaustivamente. [ cita necesaria ] La programación extrema simplemente reconoce que las pruebas rara vez son exhaustivas (porque a menudo son demasiado costosas y requieren mucho tiempo para ser económicamente viables) y proporciona orientación sobre cómo enfocar eficazmente los recursos limitados.
Fundamentalmente, el código de prueba se considera un artefacto de proyecto de primera clase, ya que se mantiene con la misma calidad que el código de implementación, sin duplicaciones. Los desarrolladores publican código de prueba unitaria en el repositorio de código junto con el código que prueba. Las pruebas unitarias exhaustivas de Extreme Programming permiten los beneficios mencionados anteriormente, como un desarrollo y refactorización de código más simple y confiable , integración de código simplificada, documentación precisa y diseños más modulares. Estas pruebas unitarias también se ejecutan constantemente como una forma de prueba de regresión .
Las pruebas unitarias también son fundamentales para el concepto de Diseño Emergente . Como el diseño emergente depende en gran medida de la refactorización, las pruebas unitarias son un componente integral. [ cita necesaria ]
Los marcos de pruebas unitarias suelen ser productos de terceros que no se distribuyen como parte del conjunto de compiladores. Ayudan a simplificar el proceso de pruebas unitarias, ya que han sido desarrollados para una amplia variedad de lenguajes .
Generalmente es posible realizar pruebas unitarias sin el soporte de un marco específico escribiendo código de cliente que ejercite las unidades bajo prueba y utilice aserciones , manejo de excepciones u otros mecanismos de flujo de control para señalar fallas. Las pruebas unitarias sin un marco son valiosas porque existe una barrera de entrada para la adopción de pruebas unitarias; tener pocas pruebas unitarias no es mejor que no tener ninguna, mientras que una vez que se implementa un marco, agregar pruebas unitarias se vuelve relativamente fácil. [17] En algunos marcos faltan muchas funciones avanzadas de pruebas unitarias o deben codificarse manualmente.
Algunos lenguajes de programación admiten directamente las pruebas unitarias. Su gramática permite la declaración directa de pruebas unitarias sin importar una biblioteca (ya sea de terceros o estándar). Además, las condiciones booleanas de las pruebas unitarias se pueden expresar con la misma sintaxis que las expresiones booleanas utilizadas en el código de pruebas no unitarias, como para qué se utiliza ify whiledeclaraciones.
Los idiomas con soporte de pruebas unitarias incorporado incluyen:
Los lenguajes con soporte para el marco de pruebas unitarias estándar incluyen:
Algunos lenguajes no tienen soporte integrado para pruebas unitarias, pero han establecido bibliotecas o marcos de pruebas unitarias. Estos idiomas incluyen:
{{cite web}}: CS1 maint: location (link)