Qual è lo scopo di Verifiable () in Moq?

125

Qual è lo scopo di Verifiable()?

Se verifico un Mocke lo tralascio, verifica comunque il file SetUp.

Modifica: stavo usando VerifyAll()quindi il motivo per cui tutto veniva verificato. Dopo il passaggio a Verify()solo i miei .Verifiable() SetUpsono stati controllati.

moq

— Castrohenge
fonte

ADDENDUM: come afferma l'altra risposta, lo scopo di .Verifiableè di arruolare un Setupin una serie di " Verify(...)chiamate differite " che possono essere attivate tramite mock.Verify().

Il chiarimento dell'OP chiarisce che questo era l'obiettivo e l'unico problema era capire perché non funzionava, ma come ha suggerito @Liam, la risposta dovrebbe davvero toccare anche questo: - I casi d'uso chiave per quanto possibile vedi sono:

mantenendo ASCIUTTO tra a mock.Setup()emock.Verify
consentendo di disconnettere la configurazione di una verifica dalla Verifychiamata stessa (ad esempio, è possibile configurarla in un altro metodo di supporto)

... e tornando alla mia risposta, che in modo conciso dice "fai attenzione perché i pro di cui sopra sono comunemente considerati controbilanciati dall'effetto che il raggiungimento di quegli obiettivi ha sulla leggibilità e manutenibilità dei test che si appoggiano troppo su tali costrutti"

ORIGINALE: si noti che, ove possibile, si dovrebbe invece seguire il layout AAA e quindi si dovrebbero fare mock.Verify( expression )chiamate esplicite dopo che il lavoro è stato fatto, piuttosto che un mock.Setup( ... ).Verifiable()accoppiato con a mock.Verify()omock.VerifyAll() ove possibile (credito: @kzu ).

— Ruben Bartelink
fonte

@EricSmith Guardando indietro, non credo di averlo messo abbastanza forte. C'è molto più vantaggio dalla suddivisione del lavoro in un raggruppamento AAA che dalla concentrazione eccessiva sugli elementi in comune tra la fase Arrange e Assert. Il 90% delle volte, c'è qualcosa da guadagnare dalle sfumature di come esprimi le chiamate di verifica alla fine, quindi dovresti impiegare molto tempo per ottimizzare per questo, anche se in alcuni casi sembra una dolorosa duplicazione. Uno dei punti che manning.com/osherove fa molto bene è che fare un test ha senso per qualcuno che si lancia è fondamentale, quindi attenersi alle convenzioni!

— Ruben Bartelink

Normalmente non sono una persona che va contro il senso della saggezza accettata, ma non sono ancora convinto dei vantaggi di AAA rispetto a Verifyable()/ VerifyAll()in tutti i casi. Il mio attuale unit test ha un numero elevato di Setup(...)chiamate (> 30). Potrebbe abbinare ciascuno di essi con un Verify () equivalente per soddisfare la convenzione, ma ciò causa una grande quantità di duplicazioni del codice e sarà più complicato da mantenere e leggere man mano che il numero di unit test cresce. Immagino che quello che sto chiedendo veramente sia se si possono fare delle eccezioni se ci sono un gran numero di setup o si evita Verifiable()una regola rigida e veloce?

— Steve Chambers

@SteveChambers Un elemento chiave di AAA è che non è A * - dovrebbe esserci un singolo atto e una singola affermazione. Quindi, mentre sei tecnicamente corretto nel dire che è meno codice per te, le coincidenze di quali dei tuoi Setup si applicano a quali (sotto) Atti e (sotto) Asserzioni diventeranno invariabilmente un campo minato. Quindi no, non è difficile e veloce, ma direi che suggerire che è anche vicino a 50:50 sarebbe un pessimo consiglio. (Si noti inoltre che non è necessario eseguire un'installazione per eseguire una verifica a meno che non si stia tentando di introdurre un comportamento particolare durante l'atto, che è ancora un altro elemento di test chiari)

— Ruben Bartelink

@Liam Ed è davvero perfetto che tu sia ancora convinto che sia uno strumento appropriato per il tuo lavoro - il mio vero punto è solo che è disapprovato come approccio generale alla scrittura di test con mock - ovvero nonostante il fatto che raggiunga ordinatamente ASCIUTTO tra a Setupe a Verify, potrebbe mancare una vittoria più alta ottenibile solo per allentare il vincolo DRY nel modo suggerito da AAA e dalla famiglia di strategie che lo implica fortemente

— Ruben Bartelink

@Liam Grazie per l'incitamento; Ho aggiornato la mia risposta perché hai ragione nel punto che stai facendo. Ai tempi in cui rispondevo a domande SO come questa, il mio punto di vista era generalmente quello di affermare in modo succinto una risposta atomica e poi lasciare che le risposte concorrenti come l'altra riempissero la mappa. In questi giorni (se mi prendessi ancora il tempo per rispondere alle domande) probabilmente proverei a dare la risposta più completa che questa è diventata in prima istanza.

— Ruben Bartelink

Quando il Verify()metodo viene chiamato alla fine del test, se una delle aspettative contrassegnate come verificabili non è stata chiamata, allora è un'eccezione thrown.

VerifyAll() non controlla le aspettative verificabili.

— Suvesh Pratapa
fonte

ti dispiacerebbe spiegare un po 'di più sul fatto che VerifyAll () non controlla le aspettative verificabili?

— JW

@JW Significa che VerifyAll verifica tutte le impostazioni senza considerare se sono state contrassegnate come aspettative verificabili.

— phoog