TDD per l'elaborazione batch: come si fa?

Mi piace "rosso / verde / refactor" per RoR, ecc.

Il mio lavoro quotidiano prevede l'elaborazione batch di file di grandi dimensioni da terze parti in Python e altri strumenti personalizzati.

L'abbandono degli attributi di questi file è elevato, quindi ci sono molte correzioni / miglioramenti applicati abbastanza frequentemente.

Non esistono test di regressione tramite un corpo noto di dati di test con risultati attesi. La cosa più vicina è in esecuzione con l'ultimo batch con nuovi casi di test codificati a mano, assicurarsi che non esploda, quindi applicare controlli a campione e test statistici per vedere se i dati sembrano ancora OK.

D >> Come portare i principi TDD in questo tipo di ambiente?

Solo un FYI: test unitari non equivalgono a TDD. TDD è un processo di cui unit testing è un elemento.

Detto questo, se stavi cercando di implementare test unitari, allora potresti fare una serie di cose:

Tutti i nuovi codici / miglioramenti vengono testati

In questo modo non è necessario passare attraverso e testare l'unità tutto ciò che già esiste, quindi la gobba iniziale dell'implementazione del test unitario è molto più piccola.

Prova singoli dati

Testare qualcosa che può contenere grandi quantità di dati può portare a molti casi limite e lacune nella copertura del test. Invece, considera l'opzione 0, 1, many. Prova un 'batch' con 0 elementi, 1 elemento e molti elementi. Nel caso di 1 elemento, testare le varie permutazioni in cui possono essere presenti i dati per quell'elemento.

Da lì, prova i casi limite (limiti superiori alla dimensione dei singoli elementi e quantità di elementi nel batch). Se si eseguono i test regolarmente e si hanno test di lunga durata (lotti di grandi dimensioni?), La maggior parte dei corridori di test consente la categorizzazione in modo da poter eseguire questi casi di test separatamente (di notte?).

Questo dovrebbe darti una base solida.

Utilizzando i dati effettivi

Inserire dati "reali" precedentemente utilizzati come quelli che stai facendo ora non è una cattiva idea. Basta completarlo con dati di test ben formati in modo da conoscere immediatamente punti specifici di errore. In caso di mancata gestione dei dati effettivi, è possibile ispezionare i risultati del processo batch, produrre un test unitario per replicare l'errore e quindi tornare a red / green / refactor con utili casi di regressione.

È lo stesso di qualsiasi altro ambiente.

Separare la logica nel suo più piccolo livello di granularità. Questo ti darà una serie di regole per il processo, ogni regola coprirà un elemento logico necessario per il tuo processo.

Quindi scrivere un test per ogni regola. Questi test falliranno. Scrivi il codice per correggere il test.

Il test di regressione con dati di test noti di cui si sta parlando non è unit test. Sarebbe un test di integrazione, questo è diverso dal TDD. Con TDD potresti avere un singolo test per verificare che potresti caricare un file, ma generalmente nessun altro test andrebbe effettivamente vicino a un file di dati con dati di test. Invece simuleresti i dati richiesti per esercitare una particolare regola usando un oggetto beffardo.

Inizia con una buona strategia software, quindi applica TDD.

(Dichiarazione di non responsabilità: potrei aver frainteso "abbandono", o TDD, o entrambi.)

Ecco la mia strategia suggerita per l'elaborazione batch di "dati sporchi": Specify-Triage-Execute.

• Elaborare una specifica dei dati in modo rigoroso e ristretto, ma coprirà la maggior parte (diciamo, 80% o più) dei dati in arrivo. Chiama questa specifica 1 .
• Sviluppa un modulo Triage (TDD se lo desideri) che decide se un record soddisfa la specifica 1.
  • Assicurarsi che il modulo funzioni molto velocemente.
  • Il modulo dovrebbe restituire vero / falso: o soddisfa tutte le regole, oppure no.
• Sviluppa un modulo Execute (TDD se lo desideri) che analizza un record noto per soddisfare la specifica 1, eseguendo le attività necessarie ai tuoi clienti.
• Applica il triage 1 su tutti i dati in arrivo.
  • Il risultato è un valore booleano per ogni record. Questo sostanzialmente separa i dati in arrivo in: Specifica 1 o Sconosciuto.
  • Applicare Esegui 1 sui dati della specifica 1, quando necessario dal cliente.
• Rilassa le regole della Specifica 1 per ammettere l'80% dei dati rimanenti. Chiama questa specifica 2 .
• Sviluppa Triage 2 ed Esegui 2 . Applicalo a tutti i dati che non soddisfano la specifica 1.
• Ripetere l'operazione per tutti i livelli necessari, fino a quando i dati rimanenti non sono sufficientemente piccoli da poter essere elaborati manualmente ogni giorno.

L'efficienza tidbit:

Salva tutti i risultati del Triage (storici o attuali) associati a un record. Se nessun modulo di triage viene modificato dall'ultima esecuzione, non è necessario eseguirlo nuovamente su vecchi dati.

Il motto "devi sapere cosa vuoi costruire prima di fare TDD":

Specify-Triage-Execute è un modo per mantenere i requisiti gestibili su ogni livello e consentire la crescita futura.

(Se qualcuno conosce i termini corretti standard per questi tre passaggi, per favore fatemi sapere, modificherò le mie risposte.)