Test Raddoppia, Mock e Stub - quando non usare e perché, per Ruby, Rspec

Vedo i test unitari come routine che testano pezzi di codice che si trovano in una base di codice che gestisci. Il mocking e lo stub aiutano a concentrarsi solo sul flusso e sulla logica del tuo codice, che è ciò che stai testando nei tuoi test unitari.

Indipendentemente dal fatto che un servizio esterno come un database (che non è intrinsecamente parte del tuo codice) funzioni effettivamente non è importante per i test unitari, ma piuttosto per test di integrazione .

So should I have a subset of tests that do test such connectivity at least and some simple operations, for example creating a record in the primary transaction detail table, even if most of the foreign keys are stubbed out?

Solo se hai implementato le routine per eseguire semplici operazioni sul database, dovresti verificare se tali routine funzionano come ti aspetti, nei test unitari. Ma in questo caso, il database verrà ancora disattivato perché non sei particolarmente interessato al fatto che il database funzioni effettivamente, stai verificando se la logica in il tuo codice funziona.

Il primo e più importante test di un componente è il test delle interfacce esterne. Scrivi prima quei test e assicurati che siano completi. Quindi aggiungi altro. Quindi esaminali, scopri quali sono i casi mancanti e aggiungili.

Quindi aggiungi altro.

Scrivi test di livello inferiore (ad esempio class-as-unit) solo quando:

1. i test di livello superiore (ad esempio componente-come-unità) stanno fallendo e non riesci a capire perché.
2. hai ancora un budget a disposizione dopo aver scritto ogni possibile test dell'interfaccia esterna.
3. hai una classe di utilità o una funzione di utilità ingegnerizzata, residente, generica o semplicemente semplice.
4. è esplicitamente richiesto dal cliente.

Per testare le interfacce esterne, ogni interfaccia sarà un input, un output o un collaboratore (come un database).

Per un test di componente come unità:

• prova le interfacce di input; chiama i metodi, asserisci i valori di ritorno.
• mock le interfacce di output; verificare che i metodi previsti siano chiamati per un dato test case.
• falso dei collaboratori; fornire un'implementazione semplice ma funzionante

Se lo fai correttamente e in modo pulito, hai a malapena bisogno di uno strumento di derisione; viene utilizzato solo poche volte per sistema. E i test unitari dovrebbero essere eseguiti in millisecondi (almeno a meno che il tuo codice non sia orrendo lento, nel qual caso forse dovresti risolverlo). Il test di integrazione sostituisce quindi i falsi e i mock, uno per uno quando lo si esegue per la prima volta o tutti tranne le interfacce utente per un test di regressione.

So should I have a subset of tests that do test such connectivity at least and some simple operations, for example creating a record in the primary transaction detail table, even if most of the foreign keys are stubbed out?

I test unitari possono e non devono mai sostituire i test di integrazione. Cioè, quando collaudi il livello dati devi sempre usare i test di integrazione in quanto non esiste alcun falso / stub al mondo che possa agire come fa il server del database.

Quindi la risposta è sì, dovresti sempre avere dei test che assicurino che il tuo codice acceda al database in modo corretto.

Si riduce al semplice fatto che devi decidere quali casi devi coprire.
Se è necessario essere sicuri della connessione al database, è necessario testarlo.

I test sono separati in gruppi in base a ciò che testano ( unità, integrazione e sistema ), dove solo i test di sistema possono effettuare chiamate reali a un database (o altro servizi).
Ogni tipo di test copre parti specifiche del sistema e ignora (o stub) le altre parti.

Ho inserito un'illustrazione schematica semplificata di seguito. i componenti all'interno della scatola verde sono testati, mentre i componenti esterni alla scatola verde sono stati cancellati (falsificati, derisi, ecc.)

per ruby / rspec ci sono strumenti (es. capibara) per aiutare con i test di sistema, spesso chiamati test di accettazione , quando sono usati per dimostrare che un sistema fa quello che dovrebbe.