stringtranslate.com

JUnit

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

JUnit se vincula como un JAR en tiempo de compilación. La última versión del marco, JUnit 5, se encuentra en el paquete org.junit.jupiter. [3] Las versiones anteriores JUnit 4 [3] y JUnit 3 se encontraban en los paquetes org.junity junit.framework, respectivamente.

Una encuesta de investigación realizada en 2013 en 10 000 proyectos Java alojados en GitHub reveló que JUnit (junto con slf4j-api ) era la biblioteca externa incluida con mayor frecuencia. El 30,7 % de los proyectos utilizaba cada biblioteca. [4]

Ciclo de vida de JUnit

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. Hay dos niveles de configuración disponibles. El primer tipo de configuración es la configuración a nivel de clase, en la que se crea y reutiliza un objeto computacionalmente costoso, como una conexión a una base de datos, con efectos secundarios mínimos. La configuración a nivel de clase se implementa utilizando la @BeforeAllanotación. El otro tipo se configura antes de ejecutar cada caso de prueba, que utiliza la @BeforeEachanotación. [5]
  2. Ejecución de la prueba: esta fase es responsable de ejecutar la prueba y verificar el resultado. El resultado de la prueba indicará si el resultado de la prueba es exitoso o fallido. @TestAquí se utiliza la anotación. [5]
  3. Fase de limpieza: después de que se hayan realizado todas las ejecuciones posteriores a la prueba, es posible que el sistema deba realizar una limpieza. De manera similar a la configuración a nivel de clase, existe una limpieza a nivel de clase correspondiente. La @AfterAllanotación se utiliza para respaldar la limpieza a nivel de clase. La @AfterEachanotación permite la limpieza después de la ejecución de la prueba. [5]

Integración con otras herramientas

JUnit 5 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]

Herramientas de construcción

JUnit es compatible con las herramientas de compilación Apache Ant , Apache Maven y Gradle , que son las herramientas de compilación de proyectos más utilizadas. [7] Las herramientas de compilación son vitales para automatizar el proceso de compilación del proyecto. [6]

Extensión de hormigas

Apache Ant, también conocido como Ant, es una de las herramientas de compilación con el mayor grado de versatilidad y tiene la historia más larga de las tres herramientas de compilación enumeradas anteriormente. [8] Ant se centra en el build.xmlarchivo, que se utiliza para configurar las tareas necesarias para ejecutar un proyecto. [8] Ant también tiene una extensión llamada Apache Ivy , que ayuda a lidiar con la resolución de dependencias. Las dependencias del proyecto se pueden declarar en el ivy.xmlarchivo. Ant puede integrarse con JUnit 5 configurando las herramientas de cobertura de código Java (JaCoCo), para el ivy.xmlarchivo. [8] Luego se ivy.xmlpuede configurar con las dependencias java-platform-consoley junit-platform-runnerpara integrarse con JUnit 5. [9]

Extensión Maven

A diferencia de Ant, Apache Maven, también conocido como Maven, utiliza un enfoque estandarizado y unificado para el proceso de compilación. [10] Maven sigue el paradigma de "convención sobre configuración" para administrar sus dependencias. [11] El código fuente de Java (o "src") se puede encontrar en el src/main/javadirectorio, y los archivos de prueba se pueden encontrar en el src/test/javadirectorio. [11] Maven se puede utilizar para cualquier proyecto Java. [10] Utiliza el Modelo de objetos de proyecto (POM), que es un enfoque basado en XML para configurar los pasos de compilación para el proyecto. [10] El Maven mínimo con el pom.xmlarchivo de compilación debe contener una lista de dependencias y un identificador de proyecto único. [10] Maven debe estar disponible en la ruta de compilación para funcionar. [10] Maven se puede integrar con JUnit 5 utilizando el jacoco-maven-plugin complemento que admite la funcionalidad lista para usar para las pruebas de JUnit 5. [12] Se pueden especificar diferentes objetivos de Maven para lograr estas tareas. [12]

Extensión de Gradle

Gradle es una herramienta de compilación que toma prestados muchos conceptos de sus predecesores, Ant y Maven. [11] Utiliza el build.gradlearchivo para declarar los pasos necesarios para la compilación del proyecto. [11] A diferencia de Ant y Maven, que están basados ​​en XML, Gradle requiere el uso de Apache Groovy , que es un lenguaje de programación basado en Java. [11] A diferencia de Ant y Maven, Gradle no requiere el uso de XML. [11] Gradle todavía se adhiere al enfoque de "convención sobre configuración" de Maven, y sigue la misma estructura para los directorios src/main/javay src/test/java. [11] Gradle puede integrarse con JUnit 5 configurando un complemento jacocojunto con el complemento junit-platform proporcionado por el equipo de JUnit 5 en el archivo de compilación. [13]

Modelo de extensión JUnit

JUnit sigue el paradigma de preferir los puntos de extensión por sobre las características. [14] El equipo de JUnit decidió no poner todas las características dentro del núcleo de JUnit, y en su lugar decidió brindar una forma extensible para que los desarrolladores aborden sus inquietudes. [14]

En JUnit 4, hay dos mecanismos de extensión: la API Runner y la API Rule. [15] Había algunas desventajas tanto en la API Runner como en la API Rule.

Una limitación importante de la API Runner es que el desarrollador tiene que implementar todo el ciclo de vida, incluso si solo necesita una etapa específica del ciclo de vida. [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 utiliza una clase de ejecutor para cada caso de prueba, y los hace incomponibles. [15] Como ejemplo, Mockito y los ejecutores parametrizados no pueden existir 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, por lo que no se pueden usar para cada caso de uso individual. [15] Solo son apropiadas cuando algo debe ocurrir antes o después de la ejecución del caso de prueba. [15] Otra limitación importante es que las reglas para las devoluciones de llamadas a nivel de clase y a nivel de método deben crearse por separado. [15]

En JUnit 5, la API de extensión se encuentra dentro del JUnit Jupiter Engine. [16] El equipo de JUnit quiere permitir que el desarrollador se conecte a etapas separadas de un ciclo de vida de prueba al proporcionar una única API de extensión unificada. [16] Al llegar a una determinada fase del ciclo de vida, el Jupiter Engine invocará todas las extensiones registradas para esa fase. [16] El desarrollador puede conectarse a cinco puntos de extensión principales: [16]

  1. Devoluciones de llamadas del ciclo de vida de prueba: esto permite al desarrollador conectarse a ciertas fases de un ciclo de vida de prueba [17]
  2. Posprocesamiento de instancia de prueba: esto permite al desarrollador realizar un gancho después de la creación de la instancia de prueba implementando la interfaz TestInstancePostProcessor. [18]
  3. Ejecución de pruebas condicional: esto permite al desarrollador ejecutar el caso de prueba solo después de cumplir ciertos criterios. [19]
  4. Resolución de parámetros: esto permite al desarrollador resolver un parámetro después de recibirlo de un método de prueba o constructor.
  5. Manejo de excepciones: un caso de uso para el manejo de excepciones es cambiar el comportamiento de prueba en lugar de lanzar una excepción. [20]

Ejemplo de un dispositivo de prueba JUnit

Un elemento de prueba JUnit es un objeto Java. Los métodos de prueba deben estar anotados con la @Test anotación . Si la situación lo requiere, [21] también es posible definir un método para que se ejecute antes (o después) de cada (o todos) los métodos de prueba con las anotaciones @BeforeEach(o @AfterEach) y @BeforeAll(o @AfterAll). [22] [23]

importar org.junit.jupiter.api.* ; clase  FoobarTests { @BeforeAll static void setUpClass () lanza Exception { // Código ejecutado antes del primer método de prueba }           @BeforeEach void setUp () lanza 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 algo más }      @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 } }

Versiones anteriores de JUnit

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

JUnit nació en un vuelo de Zurich a la 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 construyó allí, se programó en pares y se hizo la prueba primero (una forma agradable de geek metacircular).

Como efecto secundario de su amplio uso, las versiones anteriores de JUnit siguen siendo populares, y JUnit 4 tiene más de 100 000 usos por otros componentes de software en el repositorio Maven Central. [25]

En JUnit 4, las anotaciones para las devoluciones de llamadas de ejecución de pruebas eran @BeforeClass, @Before, @After, y @AfterClass, a diferencia de las @BeforeAll, , @BeforeEach, @AfterEachy @AfterAll, de JUnit 5. [22] [23]

En JUnit 3, los accesorios de prueba tenían que heredar de junit.framework.TestCase. [26] Además, los métodos de prueba tenían que tener el prefijo 'test' como prefijo. [27]

Véase también

Citas

  1. ^ "Lanzamientos de JUnit". github.com . Consultado el 23 de julio de 2023 .
  2. ^ "Cambiar licencia a EPL v2.0". github.com . 7 de septiembre de 2017 . Consultado el 4 de febrero de 2021 .
  3. ^ ab Gulati & Sharma 2017, p. 144, §Capítulo 8 Pruebas dinámicas y migración desde Junit 4.
  4. ^ "Analizamos 30.000 proyectos de GitHub: estas son las 100 mejores bibliotecas de Java, JS y Ruby". Archivado desde el original el 9 de julio de 2014. Consultado el 9 de febrero de 2014 .
  5. ^ abcd Gulati y Sharma 2017, págs. 37–40, Capítulo §2 API de ciclo de vida de JUnit.
  6. ^ ab Gulati & Sharma 2017, p. 99, Capítulo §6 Integración de herramientas.
  7. ^ Gulati y Sharma 2017, págs. 99-117, Capítulo §6 Herramientas de construcción.
  8. ^ abc Gulati & Sharma 2017, págs. 108-112, Capítulo §6 Herramientas de integración - Herramientas de construcción - Ant.
  9. ^ Gulati y Sharma 2017, págs. 116-117, Capítulo §6 Herramientas de integración - Herramientas de compilación - Extensión Ant.
  10. ^ abcde Gulati & Sharma 2017, págs. 104–108, Capítulo §6 Herramientas de integración - Herramientas de compilación - Maven.
  11. ^ abcdefg Gulati y Sharma 2017, págs. 99-103, Capítulo §6 Herramientas de integración - Herramientas de compilación - Gradle.
  12. ^ ab Gulati & Sharma 2017, p. 115, Capítulo §6 Herramientas de integración - Herramientas de compilación - Extensión Maven.
  13. ^ Gulati y Sharma 2017, págs. 113-114, Capítulo §6 Herramientas de integración - Herramientas de compilación - Extensión Gradle.
  14. ^ ab Gulati & Sharma 2017, p. 121, Capítulo §7 Modelo de extensión JUnit 5.
  15. ^ abcdefgh Gulati y Sharma 2017, págs. 121–122, Capítulo §7 Modelo de extensión JUnit 4.
  16. ^ abcd Gulati & Sharma 2017, págs. 122–124, Capítulo §7 Modelo de extensión JUnit 5 - Modelo de extensión JUnit 5.
  17. ^ Gulati y Sharma 2017, págs. 124-126, Capítulo §7 Modelo de extensión JUnit 5: devoluciones de llamadas del ciclo de vida de las pruebas.
  18. ^ Gulati y Sharma 2017, págs. 126-127, Capítulo §7 Modelo de extensión JUnit 5: posprocesamiento de instancias de prueba.
  19. ^ Gulati y Sharma 2017, pág. 127, Capítulo §7 Modelo de extensión JUnit 5 - Ejecución de pruebas condicionales.
  20. ^ Gulati y Sharma 2017, pág. 129, Capítulo §7 Modelo de extensión JUnit 5 - Manejo de excepciones.
  21. ^ Kent Beck . "Olor a configuración costosa". Wiki C2 . Consultado el 28 de noviembre de 2011 .
  22. ^ ab "Pruebas de escritura". junit.org . Consultado el 4 de febrero de 2021 .
  23. ^ ab Gulati & Sharma 2017, p. 37-40, Capítulo §2 Comprensión de CoreJunit 5.
  24. ^ "bliki: Xunidad". martinfowler.com . Consultado el 7 de marzo de 2022 .
  25. ^ "JUnit". mvnrepository.com . Consultado el 29 de octubre de 2021 .
  26. ^ Kent Beck ; Erich Gamma . "JUnit Cookbook". junit.sourceforge.net. Archivado desde el original el 2020-06-15 . Consultado el 2011-05-21 .
  27. ^ Charles A. Sharp (agosto de 2007). "Migración de JUnit 3 a JUnit 4: nada más que buenas noticias". Object Computing, Inc. Recuperado el 4 de febrero de 2021 .

Referencias

Enlaces externos