Ho un'app Web MVC cablata contro PostgreSQL. Il DB utilizza l'intera gamma di vari vincoli referenziali per garantire l'integrità referenziale, al contrario dell'approccio Rails, in cui si tenta di eseguire la maggior parte dei controlli nella logica del modello. Inoltre, per scelta, non sto usando un ORM, sto scrivendo le istruzioni SQL a mano per ogni modello.
Ora voglio scrivere test unitari e test funzionali per questo. Il problema è che se scrivo questi test contro il database (al contrario del mocking), dovrò creare un'intera lunga catena gerarchica di riferimenti per ogni modello che sto testando, oppure il sistema non mi permetterà di generarli in un vuoto. Per esempio. Non riesco a creare un modello senza una chiave esterna e la chiave esterna deve puntare a un record esistente, ecc. Lungo tutta la catena.
La cosa da ricordare è che, a differenza di un ORM, non posso fidarmi del mio livello di accesso ai dati (DAL) per funzionare come previsto. Potrei avere le dita sfiorate un'affermazione da qualche parte, o forse ho appena sbagliato la logica. Devo testare il mio livello di accesso ai dati per fare ciò che si suppone.
Un modo per risolvere questo problema è utilizzare qualcosa come Factory Girl di Rails, che, se configurato correttamente, genererà la catena di record necessaria per creare un'istanza di qualsiasi modello nel sistema. In questo modo provo sia il DAL che la logica del modello. Questo ovviamente non è l'ideale, perché i casi di test sprecerebbero un sacco di tempo a colpire il DB e aggiungere una piastra supplementare che semplicemente non ho bisogno. La mia suite andrà in tempo reale in tempo reale, il che è pessimo.
La soluzione a cui sto pensando è:
- ha una suite di test solo per il DAL. Questa suite di test si assicurerebbe di creare tutti i riferimenti giusti e testerebbe solo che le istruzioni SQL funzionino come previsto. Le referenze non saranno realmente testate esplicitamente (sembra un po 'eccessivo, ma può essere fatto se lo si desidera), ma almeno farà in modo che una catena di relazioni possa essere costruita nello scenario "percorso felice". Questa suite alla fine sarà relativamente breve e quindi non consumerà troppi cicli.
- simula sia i test del modello che quelli del controller, in modo che le cose possano essere testate in isolamento senza che i membri di riferimento del database si mettano in mezzo. È qui che si svolgerà la stragrande maggioranza dei test, quindi il beffardo DB è assolutamente logico per quanto riguarda il risparmio di tempo. In questo modo, inoltre, non sto testando il livello di accesso SQL due volte, non è necessario.
La mia domanda è: la soluzione proposta è al di sopra di come la maggior parte delle persone risolve il proprio SQL con i vincoli e il problema dei test modello / controllore, o mi manca un'opzione qui?