Stubbing e mocking boundaries

4

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 ...

  1. Scherza il modello

    • mock Post.recent
    • fai una richiesta a / post
    • asserisci che Post.recent è stato chiamato
  2. 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?

    
posta scttnlsn 17.04.2013 - 05:08
fonte

1 risposta

1

I test di integrazione aiutano a verificare che le interazioni tra tutti gli oggetti funzionino correttamente. E aiuta a delineare le funzionalità previste dell'intero sistema. Questi test sono simili a quelli in cui effettivamente provi il sistema e assicurati che funzioni. O quel QA avrebbe usato per dare una volta il sistema.

Non sei interessato a nessuno dei dettagli nel tuo controller e modello con questo test. Tutto quello che vuoi è che quando fai una determinata richiesta al sistema, una risposta data viene restituita dal sistema. Avere questi test potrebbe avvantaggiarti in modo che quando si refactoring il controller o il modello, si è in grado di verificare che non è stata interrotta alcuna funzionalità esistente. Le modifiche ai modelli utilizzati sono trasparenti per questi test.

Perché preoccuparsi di deridere / eseguire lo stub? Questo per verificare che i singoli componenti del tuo sistema funzionino. Ad esempio, con il tuo controller, dovresti inserire modelli di simulazione in modo che tu possa controllare cosa restituiscono. In questo modo si verifica che un singolo pezzo (il controller) funzioni come previsto.

In questo modo, se c'è un problema con il tuo codice (trovato come bug o test di integrazione fallito) sai che tutti i tuoi componenti funzionano correttamente e devono solo investigare le interazioni tra di loro.

Quando scrivi dei test, non stai testando componenti specifici di per sé. Piuttosto, stai testando che si verificheranno risultati specifici per determinati input.

    
risposta data 02.05.2013 - 03:52
fonte

Leggi altre domande sui tag