JUnit

JUnit es un marco de automatización de pruebas para el lenguaje de programación Java . JUnit se usa frecuentemente para pruebas unitarias y es uno de los marcos xUnit .

JUnit se enlaza como un JAR en tiempo de compilación. La última versión del framework, JUnit 6, reside en el paquete org.junit.jupiter. ^{[ 3 ]} Las versiones anteriores JUnit 4 ^{[ 3 ]} y JUnit 3 estaban en los paquetes org.junity junit.framework, respectivamente.

Una encuesta realizada en 2013 a 10 000 proyectos Java alojados en GitHub reveló que JUnit (empatada con slf4j-api ) era la biblioteca externa más utilizada. Cada biblioteca se empleaba en el 30,7 % de los proyectos. ^{[ 4 ]}

Cada clase de prueba JUnit suele tener varios casos de prueba. Estos casos de prueba están sujetos al ciclo de vida de la prueba. El ciclo de vida completo de JUnit tiene tres fases principales: ^{[ 5 ]}

1. Fase de configuración: En esta fase se prepara la infraestructura de prueba. Existen dos niveles de configuración. El primer tipo es la configuración a nivel de clase, en la que se crea y reutiliza un objeto computacionalmente costoso, como una conexión a la base de datos, con efectos secundarios mínimos. La configuración a nivel de clase se implementa mediante la @BeforeAllanotación. El otro tipo es la configuración previa a la ejecución de cada caso de prueba, que también utiliza la @BeforeEachanotación. ^{[ 5 ]}
2. Ejecución de la prueba: esta fase se encarga de ejecutar la prueba y verificar el resultado. El resultado de la prueba indicará si fue exitosa o fallida. @TestAquí se utiliza la anotación. ^{[ 5 ]}
3. Fase de limpieza: Después de ejecutar todas las pruebas posteriores, el sistema puede necesitar realizar una limpieza. Al igual que con la configuración a nivel de clase, existe una limpieza correspondiente a nivel de clase. La @AfterAllanotación se utiliza para admitir la limpieza a nivel de clase. La @AfterEachanotación permite la limpieza después de la ejecución de la prueba. ^{[ 5 ]}

JUnit 6 integra una serie de herramientas, como herramientas de compilación , entornos de desarrollo integrados (IDE), herramientas de integración continua (CI) y muchas más. ^{[ 6 ]}

JUnit sigue el paradigma de preferir los puntos de extensión a las características. ^{[ 14 ]} El equipo de JUnit decidió no incluir todas las características en el núcleo de JUnit, sino que optó por ofrecer una forma extensible para que los desarrolladores abordaran sus inquietudes. ^{[ 14 ]}

En JUnit 4, existen dos mecanismos de extensión: la API Runner y la API Rule. ^{[ 15 ]} Ambas API, Runner y Rule, presentaban algunas desventajas.

Una limitación importante de la API Runner es que los desarrolladores deben implementar todo el ciclo de vida de la prueba, incluso si solo se requiere una fase específica. ^{[ 15 ]} Esto es demasiado complicado y pesado para la mayoría de los casos de uso. ^{[ 15 ]} Otra limitación importante es que solo se puede usar una clase de runner por caso de prueba, lo que hace que los runners no sean componibles. ^{[ 15 ]} Por ejemplo, los runners de Mockito y Parameterized no se pueden usar juntos dentro de la misma clase de prueba. ^{[ 15 ]}

Una limitación importante de la API de reglas es que no puede controlar todo el ciclo de vida de la prueba y, por lo tanto, no es adecuada para ciertos casos de uso. ^{[ 15 ]} Las reglas solo son adecuadas para operaciones que necesitan ejecutarse antes o después de la ejecución de la prueba. ^{[ 15 ]} Otra limitación es que las reglas a nivel de clase y a nivel de método deben definirse por separado. ^{[ 15 ]}

En JUnit 5 y versiones posteriores, la API de extensión se encuentra dentro del motor de JUnit Jupiter. ^{[ 16 ]} El equipo de JUnit quiere permitir que el desarrollador se conecte a diferentes etapas del ciclo de vida de una prueba proporcionando una única API de extensión unificada. ^{[ 16 ]} Al llegar a una determinada fase del ciclo de vida, el motor de Jupiter invocará todas las extensiones registradas para esa fase. ^{[ 16 ]} El desarrollador puede conectarse a cinco puntos de extensión principales: ^{[ 16 ]}

1. Las funciones de devolución de llamada del ciclo de vida de las pruebas permiten a los desarrolladores ejecutar código en fases específicas del ciclo de vida de las pruebas. ^{[ 17 ]}
2. Procesamiento posterior de instancias de prueba: permite a los desarrolladores intervenir en la fase de creación de instancias de prueba mediante la TestInstancePostProcessorinterfaz. ^{[ 18 ]}
3. Ejecución de pruebas condicional: permite que las pruebas se ejecuten solo si se cumplen ciertas condiciones. ^{[ 19 ]}
4. Resolución de parámetros: permite inyectar parámetros en métodos de prueba o constructores.
5. Manejo de excepciones: permite a los desarrolladores modificar el comportamiento de la prueba en respuesta a excepciones en lugar de hacer que la prueba falle directamente. ^{[ 20 ]}

Un fixture de prueba JUnit es un objeto Java. Los métodos de prueba deben estar anotados con la @Testanotación . Si la situación lo requiere, ^{[ 21 ]} también es posible definir un método para ejecutar antes (o después) de cada uno (o todos) los métodos de prueba con las anotaciones @BeforeEach(o @AfterEach) y @BeforeAll(o @AfterAll). ^{[ 22 ] [ 23 ]}

import org.junit.jupiter.api.* ;clase FoobarTests { @BeforeAll static void setUpClass () throws Exception { // Código ejecutado antes del primer método de prueba }@BeforeEach void setUp () throws Exception { // Código ejecutado antes de cada prueba } @Test void oneThing () { // Código que prueba una cosa }@Test void anotherThing () { // Código que prueba otra cosa }@Test void somethingElse () { // Código que prueba otra cosa }@AfterEach void tearDown () throws Exception { // Código ejecutado después de cada prueba } @AfterAll static void tearDownClass () throws Exception { // Código ejecutado después del último método de prueba } }

Según Martin Fowler, uno de los primeros en adoptar JUnit: ^{[ 24 ]}

JUnit nació en un vuelo de Zúrich a la conferencia OOPSLA de 1997 en Atlanta. Kent volaba con Erich Gamma, y ​​¿qué otra cosa podían hacer dos geeks en un vuelo largo sino programar? La primera versión de JUnit se creó allí, mediante programación en parejas y con un enfoque de pruebas primero (una forma interesante de meta-recursos informáticos).

Como efecto secundario de su amplio uso, las versiones anteriores de JUnit siguen siendo populares, y JUnit 4 cuenta con más de 100.000 usos por parte de otros componentes de software en el repositorio Maven Central. ^{[ 25 ]}

En JUnit 4, las anotaciones para las devoluciones de llamada de ejecución de pruebas eran @BeforeClass, @Before, @After, y @AfterClass, a diferencia de las de JUnit 5, que eran @BeforeAll, @BeforeEach, @AfterEach, y @AfterAll. ^{[ 22 ] [ 23 ]}

En JUnit 3, los fixtures de prueba debían heredar de junit.framework.TestCase. ^{[ 26 ]} Además, los métodos de prueba debían tener el prefijo 'test'. ^{[ 27 ]}

• xUnit , el nombre de la familia que se le da a los marcos de prueba, incluido JUnit.
• SUnit , la versión original de Smalltalk escrita por Kent Beck, en la que se basó JUnit.
• TestNG , otro marco de pruebas para Java
• Objeto simulado , una técnica utilizada durante las pruebas unitarias.
• Mockito , una biblioteca de simulación para ayudar a escribir pruebas.
• EvoSuite , una herramienta para generar automáticamente pruebas JUnit.
• Lista de frameworks de Java

• Gulati, Shekhar; Sharma, Rahul (2017). Java Unit Testing with JUnit 5. Berkeley, CA: Apress . doi : 10.1007/978-1-4842-3015-2 . ISBN 978-1-4842-3014-5.

• Sitio web oficial
• Irriger, Axel. "JUnit - Herramienta de prueba unitaria de Java de código abierto" . Métodos y herramientas .
• "JUnit" . Memoria no encontrada . Tutoriales. Archivado del original el 28 de enero de 2015.