Strategia per definire i dati del dominio utilizzati nei test di integrazione

4

Nel mio lavoro lavoriamo in un'applicazione web basata sui dati e le prestazioni sono un'importante funzione aziendale. Pertanto, le query nel livello del modello sono spesso di grandi dimensioni e contengono gran parte della logica aziendale. Di conseguenza abbiamo molti test di integrazione che si basano su set di dati XML utilizzati dal nostro framework di test (un'astrazione per DbUnit) per popolare il modello di dati. Abbiamo script di migrazione contenenti DDL e modifiche al dominio dei dati che vengono eseguite prima di tutti i test, ma il framework pulisce tutte le tabelle prima dell'esecuzione di ciascun test. Stiamo valutando di modificare questo comportamento e non pulire più le tabelle di dominio. Continueremo a definire i dati dell'applicazione specifici per i test in ogni set di dati XML, ma per quanto riguarda i dati del dominio:

Dovremmo continuare a definirlo anche in ogni set di dati XML?

Pro:

  • I test non si interromperanno in caso di modifiche dei dati di dominio che non lo fanno impatto sulla logica aziendale.
  • Possiamo definire un piccolo sottoinsieme di dati di dominio sufficiente per testare la logica aziendale.

Contro:

  • Potrebbe essere necessario creare troppe tabelle e righe per rappresentare tutte le relazioni di cui il test ha bisogno.
  • Sarebbe costoso fissare i set di dati in caso di modifiche nel modello di dati.
  • Duplicazione dei dati in molti set di dati XML nel progetto.

Non dovremmo pulire i dati del dominio inseriti dagli script? Questi script verrebbero eseguiti solo una volta prima di tutti i test di integrazione e i dati sarebbero comuni a tutti i test.

Pro:

  • I test si interromperanno in caso di modifiche dei dati di dominio che influiscono sulla logica aziendale.
  • Sarebbe più semplice creare dati per il test, perché abbiamo solo bisogno di creare dati applicativi.

Contro:

  • I test potrebbero interrompersi in caso di modifiche dei dati di dominio che non influiscono sulla logica aziendale. Dovremmo fare attenzione a non testare cose come il numero di righe restituite o attributi di testo di entità di dominio.
  • Se per testare alcune logiche di business abbiamo bisogno di caratteristiche specifiche dei dati del dominio che non possiamo ritenere che sia vero nella produzione, noi è necessario modificare il dominio dei dati effettivo prima dell'esecuzione di test e rollback alla fine. Ma come cambiare qualcosa che è mutabile e imprevedibile?
posta Diego Marin 16.07.2015 - 23:35
fonte

1 risposta

1

Il mio suggerimento è un mix:

  • 1 ° passo: eseguire il test di integrazione in un database pulito, popolato e scartato a ogni esecuzione. In questo modo esegui il test del codice con la versione più recente del tuo modello di database.

  • Secondo passaggio, quando si desidera selezionare un candidato alla release dal passaggio 1, perché si desidera promuoverlo (e di solito non si promuove ogni candidato), quindi si eseguono i test di integrazione completi in una produzione come database Esegui il test degli script di migrazione e l'integrazione del tuo codice nell'ambiente di produzione.

risposta data 17.07.2015 - 04:48
fonte

Leggi altre domande sui tag