Devi utilizzare un db in memoria per i test di integrazione? [chiuso]

Do you have to use an in-memory database?

No, non devi . Ma a seconda del tipo di applicazione che si sta sviluppando e in base al tipo di test che si intende implementare, può avere alcuni vantaggi.

Pro:

I test
• possono probabilmente essere eseguiti più velocemente che su un server MySQL
• il sovraccarico amministrativo può essere più piccolo, perché vuoi che ogni dev abbia la sua istanza di database isolata e gestire un server MySQL per ogni dev probabilmente significherà più sforzo di un DB di amministrazione zero
• sarai costretto a sviluppare la tua applicazione in modo indipendente dal database (che potrebbe migliorare il design dell'app)

Contro

• non puoi utilizzare alcuna funzione MySQL che non sia disponibile anche nel sistema in-memory
• sarai costretto a sviluppare la tua applicazione in modo indipendente dal database (che potrebbe imporre alcune restrizioni e sovraccarico alla tua app)

• Cosa succede quando tutto il codice è corretto, ma il database è inattivo?
• Cosa succede quando tutto il codice è corretto, ma i dati nel database (o l'ora) sono cambiati ( select count(1) from table where date > sysdate - 1 )?
• Cosa succede quando vengono eseguiti due test unitari contemporaneamente?
• Cosa succede quando un test termina precocemente e non ripulisce?

Tutte queste cose rendono il database reale molto più difficile da utilizzare per i test unitari e ti ritroverai a trascorrere una notevole quantità di tempo cercando di renderne conto. Per i test automatici, è possibile creare falsi negativi, in cui il test fallisce ma tutto funziona correttamente. "La costruzione si è rotta, il tempo di controllare se il database fosse attivo la scorsa notte alle 2 del mattino ..." e tutte le gioie di attraversarlo per cercare di capire cosa non ha funzionato.

La chiave per i test automatici è riuscire a riprodurla. Non importa quando viene eseguito, o quale sia la situazione del resto della rete, il test automatico non dovrebbe fallire se il codice è corretto. E se hai intenzione di avere database che potrebbero essere in alto o in basso, o dati che potrebbero essere cambiati - lo sforzo aggiuntivo per cercare di farlo funzionare usando un database esterno diventa eccessivo.

Quindi, gira un database in memoria. Caricalo con i dati giusti. È solo per quell'istanza dei test (e se un'altra build si attiva mentre è in esecuzione, ottiene la propria istanza). In questo modo è più facile rieseguire il test in qualsiasi momento.

Il grosso pericolo che i test automatici falliscano a causa di qualcosa che sfugge al controllo del programmatore è che quei falsi negativi saranno un "oh, il test fallisce, potrebbe essere il database - lo controllerò più tardi" e questo inizierà ignorare i test falliti e un intervallo di tempo più lungo tra il test fallito e la correzione dei bug (quando c'è è un problema con il codice).

Ci sono librerie per rendere più semplice il test su un database - che si attiva un nuovo schema di database solo per il test. Anche se questo ha un costo aggiuntivo di manutenzione sul database (e se il database è inattivo, ancora non riesce) e attenua solo parzialmente i punti elenco all'inizio.