La risposta breve è Leggi la voce The Fine Manual sul test del database nel manuale PHPUnit .
E ora la lunga risposta...
La prima cosa da ricordare sugli unit test è che devono essere eseguiti in isolamento da tutti gli altri componenti. Spesso, questo obiettivo viene semplificato utilizzando tecniche di inversione del controllo (IoC) come iniezione di dipendenza . Quando le tue classi richiedono esplicitamente le loro dipendenze nei metodi del costruttore, è una semplice operazione per finzione quelle dipendenze in modo da poter testare il codice rimanente in isolamento.
Tuttavia, il test del codice che interagisce con i modelli è leggermente diverso. Di solito non è pratico o consigliabile iniettare i tuoi modelli nella classe in cui devi accedervi. I tuoi modelli sono generalmente strutture di dati "stupide" che espongono capacità limitate o assenti. Di conseguenza, è generalmente accettabile (in termini di testabilità) istanziare i propri modelli al volo all'interno delle classi altrimenti iniettate. Sfortunatamente, questo rende difficile testare il codice del database perché, come osserva la documentazione di PHPUnit:
Quindi, come isolare e testare il codice che interagisce con il database se i modelli non vengono iniettati direttamente? Il modo più semplice per farlo è utilizzare prove di prova .
Dal momento che stai già utilizzando PDO o una libreria ORM che si basa su PDO (giusto?), configurare le apparecchiature è semplice come eseguire il seeding di un database SQLite di base o di un file XML con i dati per ospitare i casi di test e utilizzare quella speciale connessione al database quando si testa il codice che interagisce con il database. Puoi specificare questa connessione nel tuo file bootstrap PHPUnit, ma probabilmente è semanticamente più appropriato impostare un Testcase del database PHPUnit
.
I passaggi delle best practice generalmente accettati per testare il codice DB (questi sono ripresi anche nella documentazione PHPUnit sui test DB):
- Installazione dell'apparecchiatura
- Sistema di esercizi in prova
- Verifica esito
- Smontaggio
Quindi, per riassumere, tutto ciò che devi fare è creare un dispositivo di database "fittizio" e fare in modo che il tuo codice interagisca con quei dati noti anziché con un database reale che useresti in produzione. Questo metodo ti consente di isolare correttamente il codice sottoposto a test perché tratta dati noti e ciò significa che puoi fare asserzioni specifiche/verificabili sui risultati delle tue operazioni di database.
AGGIORNAMENTO
Solo perché è una guida straordinariamente utile per ciò che non da fare nel tuo codice se vuoi promuovere la verificabilità, sto aggiungendo un link a Come scrivere 3v1L, codice non testabile . Non è coinvolto in particolare con il test del database, ma è comunque utile. Buon test!
AGGIORNAMENTO 2
Volevo rispondere al commento sulla sospensione del test del modello perché la base di codice esistente non implementa PDO per l'accesso al database:
I tuoi modelli non devono utilizzare PDO per implementare l'estensione DbUnit di PHPUnit.
Ti semplificherà la vita se usi PDO, ma non sei obbligato a farlo. Supponiamo, ad esempio, di aver creato la tua applicazione con pg_* integrato in PHP Funzioni PostgreSQL. PHPUnit ti consente comunque di specificare i dispositivi e può comunque ricostruirli per ogni test:dovresti semplicemente puntare la tua connessione quando esegui i test alla stessa risorsa utilizzata dall'estensione DbUnit per il suo dispositivo.
