TDD para el procesamiento por lotes: ¿Cómo hacerlo?

Solo un FYI: la prueba de la unidad no es equivalente a TDD. TDD es un proceso del cual la prueba unitaria es un elemento.

Dicho esto, si estuvieras buscando implementar pruebas unitarias, hay varias cosas que podrías hacer:

Se han probado todos los nuevos códigos / mejoras

De esta manera, no tienes que pasar por una prueba unitaria y todo lo que ya existe, por lo que la fase inicial de la implementación de la prueba unitaria es mucho más pequeña.

Probar datos individuales

La prueba de algo que puede contener grandes cantidades de datos puede llevar a muchos casos extremos y brechas en la cobertura de la prueba. En su lugar, considere la opción 0, 1, muchos. Pruebe un 'lote' con 0 elementos, 1 elemento y muchos elementos. En el caso de 1 elemento, pruebe las diversas permutaciones en las que se pueden encontrar los datos para ese elemento.

Desde allí, pruebe los casos de borde (límites superiores al tamaño de los elementos individuales y la cantidad de elementos en el lote). Si ejecuta las pruebas con regularidad y tiene pruebas de larga ejecución (¿lotes grandes?), La mayoría de los corredores de pruebas permiten la categorización para que pueda ejecutar esos casos de prueba por separado (¿todas las noches?).

Eso debería darte una base sólida.

Utilizando datos reales

La alimentación de datos 'reales' utilizados anteriormente como lo está haciendo ahora no es una mala idea. Simplemente complételo con datos de prueba bien formados para que sepa inmediatamente puntos específicos de falla. Si no se manejan los datos reales, puede inspeccionar los resultados del proceso por lotes, realizar una prueba unitaria para replicar el error y luego volverá a rojo / verde / refactor con casos de regresión útiles.

Es igual que cualquier otro entorno.

Separe la lógica en su nivel de granularidad más pequeño. Esto le dará un conjunto de reglas para el proceso, cada regla cubrirá un elemento de lógica que se requiere para su proceso.

Luego escribe una prueba para cada regla. Estas pruebas fallarán. Escribe el código para arreglar la prueba.

La prueba de regresión con datos de prueba conocidos de los que está hablando no es una prueba unitaria. Eso sería una prueba de integración, esto es diferente de TDD. Con TDD puede tener una sola prueba para probar que podría cargar un archivo, pero generalmente ninguna otra prueba iría cerca de un archivo de datos con datos de prueba. En su lugar, simularía los datos necesarios para ejercer una regla en particular utilizando un objeto simulado.

Comience con una buena estrategia de software, luego aplique TDD.

(Descargo de responsabilidad: es posible que haya entendido mal "churn", o TDD, o ambos.)

Aquí está mi estrategia sugerida para el procesamiento por lotes de "datos sucios": Specify-Triage-Execute.

• Redacte una especificación de los datos de manera estricta y estrecha, pero cubrirá la mayoría (es decir, el 80% o más) de los datos entrantes. Llama a esta Especificación 1 .
• Desarrolle un módulo Triage (TDD si lo desea) que decide si un registro cumple con la Especificación 1.
  • Asegúrese de que el módulo se ejecute muy rápido.
  • El módulo debe devolver verdadero / falso: cumple con todas las reglas o no.
• Desarrolle un módulo Ejecutar (TDD si lo desea) que analice un registro que se sabe que cumple con la Especificación 1, realizando las tareas que necesitan sus clientes.
• Aplique Triage 1 en todos los datos entrantes.
  • El resultado es un valor booleano para cada registro. Básicamente, esto separa los datos entrantes en: Especificación 1 o Desconocido.
  • Aplique Ejecutar 1 en los datos de la Especificación 1, siempre que el cliente lo necesite.
• Relaje las reglas de la Especificación 1 para admitir el 80% de los datos restantes. Llama a esta Especificación 2 .
• Desarrolle Triage 2 y Execute 2 . Aplíquelo a cualquier dato que no cumpla con la Especificación 1.
• Repita para tantos niveles como sea necesario, hasta que los datos restantes sean lo suficientemente pequeños para que puedan procesarse manualmente todos los días.

El dato de eficiencia:

Guarde todos los resultados de Triage (históricos o actuales) asociados con un registro. Si no se modifican los módulos de Triage desde la última ejecución, no es necesario volver a ejecutarlos en datos antiguos.

El "tiene que saber lo que quiere compilar antes de hacer TDD" tidbit:

Specify-Triage-Execute es una forma de mantener los requisitos manejables en cada nivel y permite un crecimiento futuro.

(Si alguien conoce los términos estándar correctos para esos tres pasos, hágamelo saber, editaré mis respuestas).