Tutorial de JUnit: Configuración, escritura y ejecución de pruebas unitarias de Java

¿Quieres saltarte los conceptos básicos y ver cómo automatizar generación de pruebas unitarias mejorada con IA pasar de 0 a 60%+ de cobertura de código en <5 minutos? Echa un vistazo a Jtest >>

¿Qué son las pruebas unitarias?

Primero hablemos un poco sobre que es la prueba unitaria y por qué es importante en general.

La prueba unitaria es una forma de prueba de caja blanca en la que los casos de prueba se basan en la estructura interna. El probador elige entradas para ejercer rutas particulares a través del código y configura afirmaciones que validan la salida. El propósito de las pruebas unitarias es examinar los componentes individuales o piezas de métodos/clases para verificar la funcionalidad, asegurando que el comportamiento sea el esperado.

El alcance exacto de una "unidad" a menudo se deja a la interpretación, pero una buena regla general es definir una unidad como la menor cantidad de código necesaria para realizar una tarea independiente, por ejemplo, un solo método o clase.

Hay una buena razón por la que limitamos el alcance cuando realizamos pruebas unitarias: si construimos una prueba que valida una parte amplia de un proyecto, cambiamos el enfoque de la funcionalidad de un solo método a las interacciones entre diferentes partes del código. Si la prueba falla, no sabemos por qué falló. Nos quedamos preguntándonos si el punto de falla estaba dentro del método que nos interesaba o dentro de las dependencias asociadas con ese método.

¿Qué es JUnit?

JUnit es el marco de pruebas unitarias de Java más popular. Un marco de código abierto, se utiliza para escribir y ejecutar pruebas automatizadas repetibles.

Como con cualquier otra cosa, el marco de prueba JUnit ha evolucionado con el tiempo. JUnit 4.0 se lanzó en 2006 y 5.0 se lanzó en 2017. Al momento de escribir este artículo, la última versión es 5.12.1. JUnit 5.x ha abordado muchas de las limitaciones anteriores de JUnit y se ha convertido en el marco de pruebas de unidades de Java más sólido.

Esta publicación de blog cubrirá el uso de JUnit 4 y 5.

Cómo configurar las pruebas de JUnit

Así que vamos a sumergirnos de lleno. Estos son los pasos para configurar JUnit.

Los IDE más comunes, como Eclipse e IntelliJ, ya tendrán instalada la integración de pruebas JUnit de manera predeterminada. Si no usa un IDE y tal vez depende únicamente de un sistema de compilación como Maven o Gradle, la instalación de JUnit 4/5 se maneja a través del archivo pom.xml o build.gradle, respectivamente.

Es importante tener en cuenta que JUnit 5 se dividió en 3 módulos, uno de los cuales es un módulo antiguo que admite la anotación/sintaxis de JUnit 4 y 3. El uso de JUnit 3 es muy bajo en este punto y generalmente solo se ve en proyectos mucho más antiguos.

Unidad 5

Debido al diseño modular de JUnit 5, se utiliza una Lista de Materiales (POM) para importar todos los módulos y dependencias de JUnit. Si solo se necesitan módulos específicos, se pueden especificar grupos o artefactos individuales.

Para agregar JUnit 5 a Maven, agregue lo siguiente a pom.xml:

<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>5.12.1</version>
<scope>test</scope>
</dependency>

Para Gradle, agregue lo siguiente al archivo build.gradle:

apply plugin: 'java'

dependencies {
implementation 'org.junit:junit-bom:5.12.1'
}

Unidad 4

Para agregar JUnit 4 a Maven, agregue lo siguiente a pom.xml.

<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.13.2</version>
<scope>test</scope>
</dependency>

Para Gradle, agregue lo siguiente a build.gradle:

apply plugin: 'java'

dependencies {
testCompile 'junit:junit:4.13.2'
}

Si necesita agregar manualmente JUnit a la ruta de clases para realizar pruebas con JUnit, debe referenciar directamente los archivos jar sin procesar, aunque esto no suele ser necesario. Tanto JUnit 4 como JUnit 5 tienen el archivo jar disponible para descargar directamente. Para JUnit 5, deberá descargar un archivo jar completo (también conocido como uberjar) como se describe. aquí.

Pruebas unitarias de escritura: la anatomía de un JUnit

Ahora que hemos hablado un poco sobre la configuración de JUnit, pasemos a la construcción y ejecución de estas pruebas. Para ilustrar mejor la creación de JUnits, comenzaremos con algo básico. En el siguiente ejemplo de prueba JUnit, tenemos un método simple (left) que convierte Fahrenheit a Celsius y una prueba JUnit (un Derecho) escrito para probar nuestro método. He numerado las partes clave de la prueba JUnit y discutiré cada parte en detalle a continuación.

Piezas 1 y 2

Estas son importaciones para las clases y paquetes JUnit utilizados por la prueba unitaria. Las importaciones se pueden especificar como clases individuales, pero normalmente se especifican como paquetes completos mediante asteriscos. De cualquier manera funciona: el nivel de granularidad de las importaciones es una cuestión de preferencia.

Parte 3

Esto define el inicio de nuestra clase de prueba. Lo importante a tener en cuenta aquí es la convención de nomenclatura utilizada para la clase, que es Prueba de nombre de clase. Esta convención de nomenclatura no es necesaria, pero es la forma más común de nombrar las clases JUnit porque el nombre describe de manera sucinta el propósito de la clase de prueba unitaria y qué clase está probando.

Parte 4

Aquí vemos nuestra primera sintaxis específica de JUnit: la anotación @Test. Las anotaciones son extremadamente importantes al crear JUnits. Así es como el marco JUnit identifica las partes importantes de la prueba unitaria. En nuestro ejemplo, la anotación @Test le dice a JUnit que el método public void al que está adjunto se puede ejecutar como un caso de prueba.

Hay muchas otras anotaciones, pero algunas de las más comunes son las siguientes.

• @Before identifica un método que debe ejecutarse antes de cada método de prueba en la clase. Por lo general, se usa para actualizar o restablecer el estado necesario para que los métodos de prueba se ejecuten correctamente.
• @After identifica un método que debe ejecutarse después de cada método de prueba en la clase. Se puede utilizar para restablecer variables, eliminar archivos temporales, etc.
• @Ignore especifica que no se debe ejecutar un método de prueba.
• @BeforeClass identifica un método que debe ejecutarse una vez antes de ejecutar cualquier método de prueba.
• @AfterClass identifica un método que debe ejecutarse una vez después de ejecutar todos los métodos de prueba.

Parte 5

Una vez más, tenga en cuenta la convención de nomenclatura nombre del método de prueba, donde el nombreMétodo es el nombre del método que se está probando en la clase bajo prueba.

Parte 6

En el Dado que los sección de la prueba, construimos una nueva instancia de la clase bajo prueba y la inicializamos según corresponda. Esto es necesario ya que el método de prueba necesita llamar al método bajo prueba para probarlo. En nuestro ejemplo, no se necesita ninguna otra inicialización más allá de instanciar la clase, pero en muchos casos, es posible que se deba realizar una configuración adicional, como inicializar objetos para pasar al constructor o llamar a métodos que configuran el estado de la clase bajo prueba.

Parte 7

La Cuándo La sección de la prueba incluye la inicialización de variables que deben pasarse al llamar al método que se está probando y luego llamar al método de prueba (parte 8). Las variables deben recibir valores significativos que hagan que la prueba ejerza las partes del método de prueba que nos interesan. Tenga en cuenta que si una variable es un objeto, se puede crear una instancia o burlarse de ella.

Parte 8

Si el método bajo prueba devuelve un valor, debe capturarse en una variable para que se pueda afirmar su valor.

Parte 9

Las pruebas unitarias solo son valiosas si incluyen afirmaciones que validan que el método que se está probando devuelve el valor correcto y/o ajusta el estado de otros objetos como se esperaba. Sin aserciones, no tiene verificación, y su prueba es, en el mejor de los casos, una prueba de humo que brinda retroalimentación solo cuando se lanza una excepción.

Los métodos de aserción JUnit, que se incluyen en la clase org.junit.jupiter.api.Assertions en JUnit 5 y la clase org.junit.Assert en JUnit 4, se usan comúnmente para determinar el estado de aprobación/rechazo de los casos de prueba. El marco JUnit solo informa las afirmaciones fallidas. Al igual que con las anotaciones, hay muchas opciones de afirmación.

En nuestro ejemplo JUnit anterior, usamos el método assertEquals (esperado, real, delta). El primer argumento es:

• La gastos esperados, que define el autor de la prueba.
• La salida real, que es el valor de retorno del método que se llama
• La delta, que permite una desviación aceptable entre los valores esperados y reales. Este delta es específico del hecho de que estamos validando el valor de un tipo doble.

Cómo ejecutar un JUnit

¡Elige tu propia aventura! Aquí, veremos tres formas de ejecutar JUnits: directamente desde la línea de comandos, desde el IDE (Eclipse e IntelliJ) y usando sistemas de compilación (Maven y Gradle).

Cómo ejecutar un JUnit desde la línea de comandos

Para ejecutar un JUnit directamente desde la línea de comandos, necesita algunas cosas:

• JDK en tu camino
• Los archivos jar de JUnit
• Los casos de prueba

El comando es el siguiente. Este ejemplo es para JUnit 4.

java -cp /path/to/junit.jar org.junit.runner.JUnitCore <test class name>

Nota: La ejecución de una prueba desde la línea de comandos suele realizarse desde un proceso de CI/CD que se ejecuta en un sistema de compilación como Jenkins o Azure DevOps.

Cómo ejecutar un JUnit desde el IDE

eclipsar

Dentro del Explorador de paquetes, busque su prueba JUnit. Haga clic con el botón derecho y seleccione Ejecutar como > Prueba JUnit. Esto ejecutará su prueba e informará los resultados dentro de la vista JUnit Eclipse.

IntelliJ

Ejecutar una prueba en IntelliJ es similar a Eclipse. En la ventana Proyecto, localice su prueba, haga clic con el botón derecho y seleccione Ejecutar 'testName'. Al igual que Eclipse, se abrirá una ventana JUnit con los resultados de la prueba.

Cómo ejecutar un JUnit usando sistemas de compilación

Maven

Maven ha simplificado la ejecución de pruebas unitarias. Asegúrese de estar en la ubicación adecuada desde su línea de comandos y de que el proyecto pom.xml esté configurado correctamente. Luego puede ejecutar lo siguiente para ejecutar sus JUnits.

Para ejecutar todo el conjunto de pruebas:

mvn test

Para ejecutar una(s) prueba(s) única(s)/específica(s):

mvn -Dtest=TestName test

Gradle

Gradle, como maven, ha simplificado la ejecución de pruebas.

Para ejecutar todo el conjunto de pruebas:

gradlew test

Para ejecutar una(s) prueba(s) única(s)/específica(s):

gradlew -Dtest.single=testName test

Nota: Maven y Gradle son sus propias bestias. Lo que se muestra aquí es mínimo para cubrir los conceptos básicos. Consulte su documentación si desea obtener más información.

Continuando con las pruebas unitarias

Nuestro ejemplo se ejecutó mediante una prueba unitaria simple, y por supuesto, esto es solo el comienzo de las pruebas unitarias. Los métodos más complejos que requieren prueba pueden llamar a métodos de clases dependientes o conectarse a sistemas externos como una base de datos. En estos casos, puede ser conveniente aislar el código mediante simulaciones.

La simulación ayuda a aislar unidades de código para que nuestras pruebas unitarias puedan centrarse solo en la clase/método específico que se está probando. El marco más común utilizado para burlarse en las pruebas JUnit es Mockito.

Para obtener más información sobre la burla, lea la publicación de mi colega: Cómo automatizar una prueba unitaria de Java, incluidas las burlas y las afirmaciones.

Si las pruebas unitarias son tan importantes, ¿por qué no se realizan de forma sistemática? A pesar de su importancia, no siempre son fáciles de implementar ni de mantener. Requieren un profundo conocimiento de desarrollo y un esfuerzo constante para mantener las suites de pruebas actualizadas. Como resultado, las pruebas unitarias suelen quedar relegadas a un segundo plano, hasta que se producen regresiones.

Pero no tiene por qué ser así.

Acelere las pruebas JUnit con IA

Aquí es donde entra Parasoft Jtest. Su Asistente de Pruebas Unitarias, impulsado por IA, fue diseñado para eliminar la fricción al escribir y mantener pruebas unitarias. Con solo unos clics, los equipos que comienzan con una cobertura de código del 0% pueden generar automáticamente conjuntos de pruebas robustos que cubren el 60% o más de su código Java. Como uno empresa de servicios financieros señaló: “Desde que implementamos Parasoft Jtest, hemos reducido con éxito la cantidad de tiempo que lleva crear y mantener pruebas unitarias en más del 50%”.

A continuación le mostramos cómo su equipo puede escalar su práctica de pruebas.

• Generar automáticamente casos de prueba JUnit para código previamente descubierto mediante la creación inteligente de pruebas masivas.
• Generar simulacros y stubs para aislar dependencias y enfocar sus pruebas, ahorrando tiempo y eliminando la necesidad de escribir lógica de simulación manualmente.
• Personalizar y ampliar pruebas con acciones de un solo clic para agregar afirmaciones, parametrizar casos de prueba y mejorar la capacidad de mantenimiento.
• Código modificado de destino directamente en el IDE y llene los vacíos de cobertura de pruebas más rápido con las sugerencias generadas por IA de Unit Test Assistant.
• Mantenga sus datos seguros con la IA patentada de Parasoft, que puede ejecutarse localmente, ningún código ni dato abandona su entorno.
• Acelerar la ejecución de pruebas usando incorporado análisis de impacto de prueba y Pruebas unitarias en vivo, que identifica y ejecuta solo las pruebas necesarias para validar los cambios recientes en el código.

Si escribir y mantener pruebas JUnit le ha parecido una tarea ardua, es hora de modernizar su enfoque. Soluciones de pruebas optimizadas con IA como esta pueden convertir la creación de pruebas en una ventaja estratégica, permitiéndole dedicar más tiempo a desarrollar software de calidad.