Descargo de responsabilidad

Esta es una nueva publicación de mi artículo en Medium.com con la esperanza de llegar a más desarrolladores de OSS como parte de #Hacktoberfest.

Introducción

¿Alguna vez ha tenido que lidiar con pruebas paralelizadas inestables que pasan la mayor parte del tiempo pero de repente comienzan a fallar con errores aleatorios inconsistentes? ¿Alguna vez ha tenido que arreglar pruebas que comparten los mismos archivos de recursos y modificarlas en paralelo para confundirlo a usted y a los resultados de sus otras pruebas? ¿Ha pasado innumerables noches intentando refactorizar dicho código para que pueda paralelizarse adecuadamente y tener resultados reproducibles y garantizados?

Este es un tema complejo que no siempre es sencillo de resolver, especialmente en bases de código grandes existentes. Sin embargo, seguir un conjunto simple de reglas puede ayudarte a lograrlo y el marco carlspring/idempotence tiene como objetivo ayudarte con esto.

¿Qué es el aislamiento de prueba?

Para que las pruebas sean reproducibles en todo momento, debe asegurarse de que sus archivos de recursos estén contenidos y aislados solo para ellas. Lo que esto significa es que cada prueba debe poseer exclusivamente sus recursos de prueba y otras pruebas no deben modificarlos.

¿Qué es la prueba de idempotencia?

La idempotencia de la prueba significa que sus pruebas siempre arrojarán los mismos resultados. No importa cuántas veces se hayan ejecutado y no importa qué otras pruebas se estén ejecutando en paralelo.

¿Qué es el marco carlspring/idempotence para Java?

Este es un marco liviano que ayuda a definir y copiar archivos de recursos de prueba de forma aislada para sus pruebas JUnit5. Los recursos de prueba se definen mediante anotaciones y se copian en sus propios directorios para ayudar con la implementación de la separación y el aislamiento de los recursos de prueba.

Cómo funciona el marco Java carlspring/idempotence

Todos los recursos de prueba comunes se almacenan en el directorio src/test/resources como de costumbre. Luego, cada método de prueba define los recursos que necesita mediante la anotación @TestResources. El marco copia estos recursos en un directorio aislado para cada método de prueba. Esto garantiza que tenga acceso exclusivo a los recursos que necesita, evitando la interferencia de otras pruebas que se ejecutan en paralelo, incluidos otros métodos de prueba en la misma clase de prueba.

Para cada herramienta de compilación, existe una dependencia separada que contiene lógica de transformación relacionada con la ruta para el diseño de directorio específico de esa herramienta. (Como un ejemplo muy simplificado, entre otras cosas. Maven coloca el código compilado bajo el objetivo, mientras que Gradle usa la compilación para este propósito; los recursos se colocan de manera diferente, etc.). Más sobre esto se explicará a continuación.

Cómo escribir pruebas utilizando el marco Java carlspring/idempotence

Estos son los pasos que necesitarás para comenzar.

Definir las dependencias

Deberá definir la dependencia respectiva para su herramienta de compilación. Puedes consultar cuál es la última versión lanzada aquí.

• Para Gradle (usando Groovy DSL):

testImplementation "org.carlspring.testing.idempotence:idempotence-gradle:1.0.0-rc-3"

• Gradle (usando Kotlin DSL):

testImplementation("org.carlspring.testing.idempotence:idempotence-gradle:1.0.0-rc-3")

• Para Maven:

org.carlspring.testing.idempotenceidempotence-maven1.0.0-rc-3test

Agregar anotaciones

Su clase de prueba deberá estar anotada con la anotación @ExtendWith(TestResourceExtension.class). Esta anotación es responsable de la copia real de los recursos.

También deberá anotar sus métodos de prueba con la anotación @TestResources para especificar los recursos que necesitan.

Por ejemplo:

package com.foo;

import org.carlspring.testing.idempotence.annotation.TestResource;
import org.carlspring.testing.idempotence.annotation.TestResources;
import org.carlspring.testing.idempotence.extension.TestResourceExtension;

@ExtendWith(TestResourceExtension.class)
class MyTest {

    @Test
    @TestResources({ @TestResource(source = "classpath:/foo.txt"),
                     @TestResource(source = "classpath*:/**/bar.txt")} )
    void testFoo()
    {
        // Perform whatever checks you need using these resources
    }

}

Para cada método de prueba se creará un directorio usando el siguiente formato:

• Para un proyecto Gradle, con una prueba llamada MyTest con un método testFoo, se colocarán bajo:

build/test-resources/MyTest-testFoo/nested/dir/foo.txt
build/test-resources/MyTest-testFoo/bar.txt

• Para un proyecto Maven, con una prueba llamada MyTest con un método testFoo, se colocarán bajo:

target/test-resources/MyTest-testFoo/nested/dir/foo.txt
target/test-resources/MyTest-testFoo/bar.txt

De esta manera, sus pruebas tendrán el recurso que necesitan copiado en sus propios directorios aislados. En este punto, puede modificar estos recursos de prueba a partir de los métodos de prueba a los que pertenecen y sus resultados deben ser idempotentes, siempre que solo dependan de recursos basados ​​en archivos y no de otros tipos de recursos compartidos (base de datos, servicios de terceros, etc.).

Dónde encontrar la documentación

La documentación del proyecto Idempotence se puede encontrar aquí.

Puedes echar un vistazo a la descripción general conceptual para obtener una explicación más detallada de cómo funcionan las cosas.

Como contribuir

Este es un proyecto totalmente nuevo que cuenta con la funcionalidad y la infraestructura principales, pero la ayuda siempre es bienvenida.

Los colaboradores que tengan experiencia con JUnit, Springframework y MkDocs podrían ayudar a darle forma al proyecto con algunas ideas y soluciones excelentes. ¡Los primeros usuarios que puedan proporcionar comentarios también son bienvenidos!

Los problemas etiquetados como hacktoberfest o se busca ayuda están disponibles y deberían ayudarte a comenzar rápidamente. Puedes encontrarlos aquí.

Conclusión

Una de las cosas más importantes al escribir casos de prueba son los datos de prueba que utilizarán las pruebas y mantenerlos sanos entre ejecuciones. Si sigue un conjunto de reglas simples para mantener estos datos aislados entre sus pruebas, puede lograr idempotencia y confiabilidad en sus resultados.

El proyecto carlspring/idempotence proporciona un marco fácil de usar que es adecuado tanto para proyectos nuevos como para legados de refactorización.