Derivando operazioni di dati complessi nei test di integrazione

2

Abbiamo alcuni problemi a capire come eseguire il mocking di dati e operazioni complessi su di esso.

Innanzitutto i problemi con la generazione di dati complessi:

In uno dei nostri componenti abbiamo strutture dati davvero complesse in cui viene eseguita la logica delle nostre classi. Sfortunatamente ci sono alcuni bug, in cui è necessario utilizzare un modello di big data per riprodurre il caso in un'unità o test di integrazione. La prima idea era di scrivere uno script che converta il modello in codice eseguibile, con il quale i dati possono essere generati. Per mostrare la complessità dei modelli, questi modelli convertiti avevano una riga di codice 20000 ++ per modello.

Il problema con il primo approccio era che avevamo alcuni piccoli errori nel nostro script e ogni volta che ne identificavamo uno dovevamo riscrivere tutti i modelli. Non era una buona idea. La seconda idea è usare i file xml in cui sono salvati. Prima che inizi il test, usiamo una classe per convertire il file xml nel modello. Il risultato è migliore della prima idea, ma con questo non avremo mai dei semplici test unitari, perché facciamo sempre affidamento sulla classe utilizzata per la conversione.

Qualcuno ha un'idea migliore di come affrontare questo problema?

Il secondo problema è ancora più difficile da risolvere: la manipolazione di questi dati complessi.

Abbiamo un test di integrazione di un altro componente e vogliamo prendere in giro tutte le sue dipendenze. In qualche modo creiamo i dati iniziali utilizzati dal componente (una sorta di AST). Ora abbiamo un componente di controllo della sintassi come dipendenza. Questo componente prende i dati e decora i dati. Quindi alla fine abbiamo un altro AST manipolato nel test.

Qui non abbiamo idea di come deridere questo comportamento del controllo della sintassi.

    
posta Yggdrasil 17.07.2013 - 09:02
fonte

1 risposta

1
   > We use a class to convert the xml file to the model. ... 
   > But with this we will never have plain unit tests.

Usiamo un approccio simile. Dal momento che abbiamo già serializzazione json (de-) usiamo questo invece di xml. I dati di esempio sono inclusi come risorsa-test, quindi non ci basiamo su file system-stream per utilizzare i dati.

Per ridurre ulteriormente la dipendenza da test su enormi modelli di dati nel modello, separa il modello di navigazione dal calcolo di modell-businesslogic.

Esiste un metodo modell-businesslogic-calcolo-statico senza navigazione

Order.calculateTotal(IOrderItem[] items, ICustomer customer)

e un metodo che utilizza i metodi di navigazione

Order.calculateTotal() {Order.calculateTotal(this.getItems(), this.getCustomer())}

Per testare il calcolo dell'ordine-businesslogic, non è necessario prendere in giro un Order . Usiamo il metodo di ordine statico interno-businesslogic-calculation-method che non ha dipendenze da Order-OrderItems e Order-Customer.

Per test La manipolazione di questi dati complessi dà un'occhiata a approvaltests . approvaltests registrano effettivamente test-output e fallisce se l'output di test è cambiato. Quindi un umano deve approvare che il calcolo è ok. Alla successiva esecuzione del test approvato, il test non fallirà più (fino a quando l'output non cambierà di nuovo)

    
risposta data 17.07.2013 - 09:38
fonte

Leggi altre domande sui tag