Va bene creare e rilasciare i database durante i test unitari

La prima cosa da notare è che, se si stanno creando e rilasciando DB come parte dei test, non si tratta di test unitari; sono meglio descritti come test di integrazione.

Pedantic point aside, quindi la domanda chiave è, ogni test crea un DB diverso, quindi i test possono essere eseguiti in parallelo? Oppure due test in esecuzione contemporaneamente interferiscono l'uno con l'altro (ad esempio facendo cadere il DB a metà del test dell'altro)?

Se non possono essere eseguiti in parallelo, non si ottiene un buon ritorno sull'investimento nel tempo in cui ogni test esegue il proprio setup e smantellamento. Se lo hai spostato nella configurazione del test suit e nella funzionalità di teardown, non avresti riscontrato nuovi problemi di conflitto tra i test e avresti accelerato i singoli test.

Se possono essere eseguiti in parallelo, si riduce a una scelta. Avere ogni test per creare e distruggere il proprio DB è più pulito, ma è più lento. Quindi scegli tra i due.

Sarà lento, questo è il principale svantaggio. Potrebbe non essere un problema se hai una dozzina di test, ma quando ne hai centinaia potrebbe essere un vero problema.

I am not sure if creating / dropping a database is such a lightweight operation as creating / deleting a file...

Di certo non lo è. Una creazione / eliminazione di file (sia locale che remota) sarebbe normalmente molto più veloce.

Penso che la velocità dell'esecuzione del test unitario sia il tuo problema qui (e potrebbe essere abbastanza veloce da non preoccuparti). Normalmente si desidera che i test siano sufficientemente veloci da essere eseguiti ripetutamente e non costituiscano un collo di bottiglia per lo sviluppo / la distribuzione. Se sei in grado di trasformare questi database abbastanza velocemente, non è un problema. Tuttavia, se continuerai ad aggiungere casi simili, la scalabilità diventerà un problema, e guarderei (diciamo) inizializzando un database per test suite o simile.