Sto eseguendo test dallo stesso database che utilizzo nello sviluppo. Ricordo di aver usato Rails e ho usato un database separato per i test (principalmente il tutorial su cui stavo andando così detto). Ha avuto un senso comunque. Mi stavo chiedendo che questo fosse il modo comune di fare le cose o se esistesse un'alternativa. Qualcuno può far luce su questo?
Abbastanza comune, ma ... è il risultato di un uso improprio di PHPUnit
È importante distinguere i test unitari dai test di integrazione e dai test di accettazione.
Lo scopo principale di PHPUnit è la scrittura di unit test.
Il test unitario dovrebbe testare "unità" isolate (funzioni, metodi pubblici). Tutto il resto, incluso il database, viene emulato tramite Test Doubles (Mock). Quindi, se hai bisogno di testare il metodo del tuo controller, "prendi in giro" le classi del modello in modo che restituiscano risposte predefinite (o generate casualmente). Se hai bisogno di testare il modello ti prendi in giro le classi di accesso a db e, portando questo al limite, se hai bisogno di testare il driver db, prendi in giro il socket-layer per restituire sequenze di byte specifiche.
D'altra parte è possibile utilizzare PHPUnit per i test di accettazione (anche se ci sono strumenti migliori per questo). I test di accettazione nelle applicazioni web dovrebbero falsare le richieste web e verificare che l'applicazione restituisca le risposte appropriate. È molto consigliabile controllare l'intero stack, quindi le richieste dovrebbero colpire il database alla fine. In questo caso è consigliabile utilizzare un database separato, in modo che i test non danneggino i dati di produzione.
Ero solito (non in PHP ammettiamolo, ma questo vale per ogni DB) test stored procedure sul DB di sviluppo.
I DB hanno transazioni. Quindi avviarne uno, troncare le tabelle, inserire i dati di test, eseguire test e quindi eseguire il rollback. Il tuo DB tornerà al suo vecchio stato. Semplice.