Supponiamo che sto creando un'API JSON e vorrei includere un endpoint che restituisca un elenco di post creati di recente. Da qualche parte nel mio sistema c'è un modello Post esistente con il seguente test:
- crea alcuni post nel db (alcuni nuovi, alcuni vecchi)
- post = Post.recent
- asserisci che i post contengono solo nuovi post
Ora voglio testare il drive dell'endpoint JSON che avvolge questa funzionalità (il "controller"). Il modo più ovvio per testare questo sarebbe un test di integrazione completo come:
- crea alcuni post nel db (alcuni nuovi, alcuni vecchi)
- fai una richiesta a / post
- asserisce che solo i nuovi post sono stati restituiti nella risposta
Questo sembra duplicare gran parte di ciò che è già stato testato nel modello e inizierà a rallentare la suite di test dato che devono essere testati più percorsi di codice (cioè auth, parametri della stringa di query, ecc.). Le alternative ...
-
Scherza il modello
- mock Post.recent
- fai una richiesta a / post
- asserisci che Post.recent è stato chiamato
-
Stub il modello
- stub Post.recent
- fai una richiesta a / post
- asserire che i post stub sono stati restituiti nella risposta
Una di queste opzioni da sola non sembra sufficiente per testare completamente il controller, ma quando combinato sembra abbastanza completo. Il pezzo che non viene testato è l'accordo tra il modello e il controller su Post.recent. Cosa succede se decido di ridefinire il mio modello e i test dei modelli e Post.recent non esiste più ... i miei test continueranno a passare anche se il sistema di produzione fallirà.
Come si indirizza questo? I test di integrazione sono l'unica risposta? Se è così, perché preoccuparsi di sopprimere e deridere?