Quando è il test di interazione (verifica di chiamata) mentre il test di unità è considerato eccessivo?

Question

Quando è il test di interazione (verifica di chiamata) mentre il test di unità è considerato eccessivo?

#1 da (4 voti)

3

Ho l'impressione che il test di interazione (verificando le invocazioni fittizie) in generale dovrebbe essere evitato.

Quando invece dovrebbe essere asserito il metodo di prova unitario.

Tuttavia ci sono casi in cui il test di interazione non può essere evitato. In questi rari casi, ritengo che il test di interazione sia consentito.

Casi in cui il test di interazione è ok (ma continua a farlo in modo consapevole)

facilita il cambiamento di stato (cambio di stato attraverso un servizio)
l'interazione è side-effectful (accesso al database, chiamata di rete attraverso un servizio, invocazione a un osservatore)

Tuttavia sembra esserci un sacco di argomenti per l'interazione per . In particolare, per assicurarti che:

le invocazioni si verificano (anche per le interazioni effetive non laterali)
non si verificano invocazioni extra

Penso che questi casi rientrino nella categoria dei dettagli di implementazione e non dovrebbero essere più testati. Mentre questi casi hanno un punto, i test per la maggior parte degli scenari di implementazione avranno queste carenze. E penso che ci dovrebbe essere un certo livello di fiducia che nessuno sviluppatore nel team scriverà codice che dice ad esempio: aggiorna un'entità e la salva nel database su un metodo di query (chiara violazione di LSP , CQS e principio di minimo stupore).

Inoltre, in questi casi, a mio avviso, il test unitario tende a rispecchiare il codice sotto test troppo da vicino, e fallisce inutilmente quando il codice in prova cambia (indipendentemente dall'effetto sul comportamento) rendendo i test troppo fragili, rendendo così perdono il loro valore.

Quali sono le tue opinioni in merito?

tdd testing unit-testing design

posta Chad 28.02.2017 - 07:42

fonte

1 risposta

Leggi altre domande sui tag tdd testing unit-testing design

Il nodo di un albero ha un antenato? API - Limitazione dell'accesso alle risorse create dall'utente autenticato

score 4 · Answer 1

Cases where interaction testing is ok (but still do it mindfully)

Questo sembra un buon motivo per vivere. Troppe persone vietano i test di interazione a causa della loro fragilità, ma dimenticano che possono farti guadagnare fiducia sulla correttezza ad un costo inferiore. I mock sono più facili da configurare ed eseguire più velocemente degli equivalenti del test di integrazione ai confini di un sistema, quando comunicano con un DB, il file system, la rete, ecc.

Vorrei aggiungere un altro caso: quando stai progettando un'applicazione dall'esterno e stai ancora scoprendo quali grandi categorie di classi sono necessarie e le dipendenze tra di esse.

I test di interazione basati su interfacce e simulazioni consentono di definire protocolli, ovvero i contratti di discussione tra componenti, senza dover implementare immediatamente i loro meccanismi interni. Questi test possono anche essere trattati come meri scaffolding e cancellati quando il design è asciutto.

invocations do happen (even for non side effectful interactions)

no extra invocations happen

I think these cases fall into the implementation detail category and should not be tested anymore.

Sì, testare che qualcosa non fosse accadere sembra superfluo il più delle volte. Ecco perché non confondo le mie verifiche simulate con opzioni di controllo extra come Times.Once o asserzioni su metodi che non entrano in gioco nello scenario di test. Questo parla dell'uso "consapevole" dei mock che stai menzionando.

Riguardo alle azioni non intenzionali, c'è teoria e pratica. Considero la modifica dello stato di un oggetto come un effetto collaterale. Non può sempre essere verificato tramite la verifica dello stato, perché l'oggetto non (non dovrebbe) esporre sempre il suo stato interno. Non può essere sempre verificato tramite mock perché la maggior parte dei framework di derisione (almeno nelle lingue tipizzate staticamente) non ti consente di simulare i tipi di calcestruzzo. C'è una sorta di area grigia in cui i vincoli tecnici superano le linee guida di progettazione.

Se l'azione è puramente non-effect effectful (cioè una chiamata a una funzione referentially transparent in FP gergo), non testerei l'interazione ma l'output della funzione. Ma non è spesso il caso nei programmi OO e il controllo di una chiamata a una simulazione a volte è una soluzione quando la dipendenza è irrisoria.