por Douglas Campbell, ingeniero principal

I/E/A – entrada/espera/actual

Si puede proporcionar implementaciones para el conjunto de funciones siguientes,

// defines how to go from file to an instance of IN
abstract IN loadInput(File input);

// defines how to go from file to OUT instances
// throw FNF whenever there’s no expected file.
abstract OUT loadOutput(File expected) throws FileNotFoundException;

// invoked upon missing expected file or if actual != expected
abstract void storeResult(OUT result, File resultFile);

se puede hacer mucho para quitar la monotonía de las pruebas de transformaciones de documentos y mantener un conjunto robusto de pruebas.

En Resumen, se convierte en casos de prueba de escritura trivial como archivos en lugar de funciones.

Yo prefiero este enfoque para probar la transformación de documentos que Mucking con código de prueba. Primero, un poco de fondo.

Fondo

Gran parte del código que he escrito a lo largo de los años tiene en su núcleo el cambio de documentos de un formato a otro. Por los documentos, estoy hablando de cualquier variedad de JSON, XML, Avro, tabulación delimitada, YAML, lo que sea-cualquier cosa y todo a cualquier cosa y todo y de nuevo.

Cuando se le pide que codifique cosas como esta, muchos de los ojos de dev simplemente rollover en el horror de escribir algo tan trivial como la cartografía de un campo a otro, de la parte superior de la carcasa, la fusión con otro valor leído de algún origen de datos externo, y luego la puesta en otro Representación.

Esa nueva representación puede tener poca semejanza con el doc inicial. Esa es la naturaleza de la bestia.

¡ En Resumen, los requisitos para conducir transformaciones de datos son completamente arbitrarios!

Creo que esta es la razón por la que algunos Devs odian estas cosas. Ellos toman atajos y tirar cosas en código de prueba que se parecen a esto...

//CHECKSTYLE:OFF
private static final String CLICK = "a horrendously ugly line of input from an access log";
//CHECKSTYLE:ON

Y cuando es el momento de probar una "impresión" Adivina lo que pasa. UGH – prueba de entrada en línea como variables de cadena. ¡ Sentido arácnido inmediatamente activado tras la supresión de Checkstyle!

Una cosa que he aprendido es que dondequiera que haya temor y evitación, eso es exactamente donde se necesita una pereza excesivamente enérgica. Retrocede. Hágalo muerto simple y deshacerse de los escariados y escariados de la lógica duplicada y o código. Escribir una función para ejecutar una carpeta completa llena de pruebas

// test folder of tests and fail entire run if any fail.
public void testFolder(File testfolder, Function<IN, OUT> converter) {

    for (File test: testfolder.listFiles(testFileFilter)) {
        if (!testSingle(test, converter)) {
           fail("expected != actual - actual " +
           "results saved in .actual file");
        };
    }
}

¿Y qué de esta función testSingle? Muy sencillo con las tres funciones definidas al inicio del blog.

// test a single test
private boolean testSingle(File test, Function converter) {
    IN input = loadInput(test);
    OUT actual = converter.apply(input);
    OUT expected = null;

    // only create if no expected file or result is different.
    File actualFile = new File(test.getParent(),
                               test.getName() + ".actual");

    try {
        expected = loadOutput(new File(test.getParent(),
                                       test.getName()
                                       + ".expected"));

    } catch (FileNotFoundException ex) {
        // we haven't got expected file - no biggie
        // we can turn this into an expected file once
        // satisfied with it.
        storeResult(actual, actualFile);
    }
    return false;

    // we've got something to compare
    if (!actual.equals(expected)) {
        // fail and save the actual file for command
        // line diffing
        storeResult(actual, actualFile);
        return false;
    }

    return true;
}

Beneficios misceláneos de este enfoque

Para documentos basados en texto o ASCII, la utilidad diff está disponible inmediatamente para comparar las fallas de prueba

Usted no tiene que escribir código de prueba para generar lo que su salida esperada es. Simplemente añada su registro de muestra a la carpeta tests, ejecute las pruebas y la salida real se genera a un nuevo archivo con extensión. real

Usted tiene una manera inmediata de ejecutar su código sobre los registros que le han causado problemas en la producción. De nuevo, suelte el registro problemático en la carpeta de prueba y ejecute la prueba.

Si su equipo decide construir un nuevo convertidor o utilizar una biblioteca JSON diferente, todas sus pruebas se expresan como archivos independientes del idioma. Puedes llevarlos hacia adelante.

Cosas para llegar justo al frente

En primer lugar, tenga cuidado de hacer su transformación lógica apátrida. Esencialmente, las transformaciones de documentos que implican llamadas fuera de proceso necesitan ser rehechas para separar la recuperación de datos crudos de lo que se le hace.

En segundo lugar, comience a hacer esto al principio en el ciclo de duración del módulo de código o app. Los apetitos suelen ser bastante magros para dar vueltas y volver a trabajar viejas pruebas repulsivas.

Siguiente paso

Un siguiente paso para nosotros es empaquetar esto como un paquete de prueba de código abierto. Quién sabe, puede que suceda antes si tenemos un poco de interés.