TDD per l'elaborazione in batch: come si fa?

14

Mi piace "red / green / refactor" per RoR, ecc. bene.

Il lavoro del mio giorno comporta l'elaborazione in batch di file molto grandi da terze parti in python e altri strumenti personalizzati.

Agganciare gli attributi di questi file è alto, quindi ci sono molte correzioni / miglioramenti applicati molto frequentemente.

Il test di regressione tramite un corpo conosciuto di dati di test con risultati previsti non esiste. La cosa più vicina è correre contro l'ultimo batch con nuovi casi testati codificati a mano, assicurarsi che non esplodano, quindi applicare controlli spot e statistici per vedere se i dati sembrano ancora OK.

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

    
posta user6130 22.10.2010 - 20:49
fonte

3 risposte

5

Solo una FYI: il test dell'unità non è equivalente a TDD. TDD è un processo in cui il test unitario è un elemento.

Detto ciò, se stavi cercando di implementare i test unitari, ci sono un sacco di cose che potresti fare:

Tutti i nuovi codici / miglioramenti sono testati

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

Verifica singoli pezzi di dati

Il test di 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, molte. Prova un 'gruppo' con 0 elementi, 1 elemento e molti elementi. Nel caso di 1 elemento, verifica le varie permutazioni in cui possono essere contenuti 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 regolarmente i test e si eseguono test a lungo termine (lotti di grandi dimensioni?), La maggior parte dei test runner consente la categorizzazione in modo che sia possibile eseguire tali test case separatamente (di notte?).

Questo dovrebbe darti una base strong.

Utilizzo dei dati reali

L'inserimento di dati "effettivi" precedentemente utilizzati come quello che stai facendo ora non è una cattiva idea. Basta integrarlo con dati di test ben formati in modo da conoscere immediatamente specifici punti di errore. In caso di mancata gestione dei dati effettivi, è possibile esaminare i risultati del processo batch, produrre un test unitario per replicare l'errore, e quindi tornare in rosso / verde / refactoring con casi di regressione utili.

    
risposta data 22.10.2010 - 21:23
fonte
1

È uguale a qualsiasi altro ambiente.

Separa la logica nel suo più piccolo livello di granularità. Questo ti darà un insieme di regole per il processo, ogni regola coprirà una voce di logica richiesta per il tuo processo.

Quindi scrivi 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 è un test unitario. Quello sarebbe test di integrazione, questo è diverso da TDD. Con TDD è possibile avere un singolo test per verificare che è possibile caricare un file, ma generalmente nessun altro test si avvicina effettivamente a un file di dati con dati di test. Invece dovresti simulare i dati richiesti per esercitare una particolare regola usando un oggetto di simulazione.

    
risposta data 22.10.2010 - 21:23
fonte
1

Inizia con una buona strategia software, quindi applica TDD.

(Disclaimer: potrei aver frainteso "churn", o TDD, o entrambi.)

Ecco la mia strategia suggerita per l'elaborazione in batch di "dati sporchi": Specifica-Triage-Esegui.

  • Disegna una specifica dei dati in modo rigoroso e stretto, ma coprirà la maggior parte (ad esempio, 80% o più) dei dati in arrivo. Chiama questo Specifica 1 .
  • Sviluppa un modulo Triage (TDD se lo desideri) che decide se un record soddisfa la Specifica 1.
    • Assicurati che il modulo funzioni molto velocemente.
    • Il modulo dovrebbe restituire true / false: o soddisfa tutte le regole, oppure no.
  • Sviluppa un modulo Esegui (TDD se lo desideri) che analizza un record noto per soddisfare la specifica 1, eseguendo qualsiasi attività richiesta dai clienti.
  • Applica Triage 1 su tutti i dati in arrivo.
    • Il risultato è un valore booleano per ogni record. In pratica separa i dati in entrata in: Specifica 1 o Sconosciuto.
    • Applica Esegui 1 nei dati della specifica 1, quando richiesto dal cliente.
  • Rilassa le regole della Specifica 1 per ammettere l'80% dei dati rimanenti. Chiama questa Specifica 2 .
  • Sviluppa Triage 2 e Esegui 2 . Applicalo a tutti i dati che non soddisfano la Specifica 1.
  • Ripeti per tutti i livelli necessari, fino a quando i dati rimanenti sono abbastanza piccoli da poter essere elaborati manualmente ogni giorno.

Il tidbit dell'efficienza:

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

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

Specificare-Triage-Execute è un modo per mantenere i requisiti gestibili su ogni livello e consente una crescita futura.

(Se qualcuno conosce i termini corretti standard per questi tre passaggi, fammi sapere, modifico le mie risposte.)

    
risposta data 05.12.2010 - 02:24
fonte

Leggi altre domande sui tag