TDD para procesamiento por lotes: ¿cómo hacerlo?

Me gusta "rojo / verde / refactor" para RoR, etc. bien.

Mi trabajo diario implica el procesamiento por lotes de archivos muy grandes de terceros en Python y otras herramientas personalizadas.

La reducción de los atributos de estos archivos es alta, por lo que hay muchas correcciones / mejoras que se aplican con bastante frecuencia.

La prueba de regresión a través de un cuerpo conocido de datos de prueba con los resultados esperados no existe. Lo más cercano es correr contra el último lote con nuevos casos de prueba codificados a mano, asegúrese de que no explote, luego aplique pruebas de verificación y estadísticas para ver si los datos aún se ven bien.

P >> ¿Cómo incorporar los principios TDD a este tipo de entorno?

Solo un FYI: las pruebas unitarias no son equivalentes a TDD. TDD es un proceso en el que las pruebas unitarias son un elemento.

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

Todos los nuevos códigos / mejoras son probados

De esta manera, no tiene que pasar y probar la unidad todo lo que ya existe, por lo que el obstáculo inicial de implementar la prueba de la unidad es mucho menor.

Probar piezas individuales de datos

Probar algo que puede contener grandes cantidades de datos puede generar muchos casos extremos y lagunas en la cobertura de la prueba. En cambio, 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 que pueden estar los datos para ese elemento.

A partir de ahí, pruebe los casos límite (límites superiores al tamaño de los elementos individuales y la cantidad de elementos en el lote). Si ejecuta las pruebas regularmente y tiene pruebas de ejecución prolongada (¿lotes grandes?), La mayoría de los corredores de prueba 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.

Usando datos reales

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

Es lo mismo que cualquier otro entorno.

Separe la lógica en su nivel más pequeño de granularidad. 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 puede cargar un archivo, pero en general ninguna otra prueba se acercaría a un archivo de datos con datos de prueba. En su lugar, simularía los datos necesarios para ejercer una regla particular utilizando un objeto de burla.

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

(Descargo de responsabilidad: es posible que haya entendido mal "abandono", 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 forma estricta y estrecha, pero cubrirá la mayoría (digamos, el 80% o más) de los datos entrantes. Llame a esta especificación 1 .
• Desarrolle un módulo de Triaje (TDD si lo desea) que decida si un registro cumple con la Especificación 1.
  • Asegúrese de que el módulo funcione muy rápido.
  • El módulo debe devolver verdadero / falso: cumple con todas las reglas o no.
• Desarrollar un módulo Ejecutar (TDD si lo desea) que analiza un registro que se sabe que cumple con la Especificación 1, realizando cualquier tarea que necesiten sus clientes.
• Aplicar 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. Llame a esta especificación 2 .
• Desarrollar Triage 2 y Ejecutar 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 como para que puedan procesarse manualmente todos los días.

El tidbit de eficiencia:

Guarde todos los resultados de Triaje (históricos o actuales) asociados con un registro. Si no se modificó ningún módulo Triage desde la última ejecución, entonces no es necesario volver a ejecutarlo con datos antiguos.

El tidbit "tienes que saber lo que quieres construir antes de hacer TDD":

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 correctos estándar para esos tres pasos, hágamelo saber, editaré mis respuestas).