Test di integrazione del database

Question

Quando esegui test di integrazione solo con il livello di accesso ai dati o con la maggior parte dello stack dell'applicazione.Qual è il modo migliore per evitare che più test entrino in conflitto tra loro se vengono eseguiti sullo stesso database?

Answer 1

Transazioni.

Ciò che fa il framework di test unitario Ruby on Rails è questo:

Load all fixture data.

For each test:

  BEGIN TRANSACTION

    # Yield control to user code

  ROLLBACK TRANSACTION

End for each

Ciò significa che

1. Qualsiasi modifica apportata dal test al database non influirà sugli altri thread mentre è in corso
2. I dati del test successivo non vengono inquinati dai test precedenti
3. Questo è circa un milione di volte più veloce rispetto al ricaricamento manuale dei dati per ciascun test.

Per quanto mi riguarda, penso che sia piuttosto interessante

Answer 2

Per semplici applicazioni di database che trovo utilizzando SQLite inestimabile.Ti consente di avere un database unico e autonomo per ogni test.

Tuttavia funziona solo se stai utilizzando semplici funzionalità SQL generiche o puoi facilmente nascondere le lievi differenze tra SQLite e il tuo sistema di database di produzione dietro una classe, ma ho sempre trovato che fosse abbastanza semplice nelle applicazioni SQL che ho sviluppato.

Answer 3

Solo per aggiungere alla risposta di Free Wildebeest che ho usato anche io HSQLDB per eseguire un test di tipo simile in cui ogni test ottiene un'istanza pulita del DB.

Answer 4

Volevo accettare sia la risposta di Free Wildebeest che quella di Orion Edwards, ma non me lo permetteva.Il motivo per cui ho voluto farlo è che sono giunto alla conclusione che questi erano i due modi principali per farlo, ma quale scegliere dipende dal singolo caso (principalmente dalla dimensione del database).

Answer 5

Inoltre, esegui i test in momenti diversi, in modo che non incidano reciprocamente sulle prestazioni o sulla validità.

Answer 6

Sebbene non sia intelligente come il framework di unit test di Rails in una delle altre risposte qui, creare dati distinti per test o gruppo di test è un altro modo per farlo.Il livello di noiosità di questa soluzione dipende dal numero di casi di test disponibili e dalla loro dipendenza l'uno dall'altro.La noiosità rimarrà vera se si dispone di un database per test o gruppo di test dipendenti.

Quando si esegue la suite di test, si caricano i dati all'inizio, si esegue la suite di test, si scaricano/confrontano i risultati assicurandosi che il risultato effettivo soddisfi il risultato atteso.In caso contrario, ripetere il ciclo.Carica, esegui la suite, scarica/confronta.