Qual è l'idea dietro l'accesso ai dati mocking nei test unitari [duplicato]

Question

Qual è l'idea dietro l'accesso ai dati mocking nei test unitari [duplicato]

#1 da (7 voti)
#2 da (5 voti)
#3 da (1 voti)

3

Capisco che in realtà non dovresti colpire il database o il disco quando fai dei test unitari ... Perché?

Inoltre, prendendo qualcosa come Moq, che cosa dovrebbe effettivamente prendere in giro e dove? Ad esempio, supponiamo di voler creare un metodo chiamato "loadconfig" che carica un documento XML. Questo sarebbe un metodo vuoto, quindi verificherei che abbia funzionato scrivendo dei test attorno ai metodi di valore get / set ...

Quindi Moq dovrebbe imitare un file che viene caricato? E devo anche prendere in giro il ritorno / l'impostazione dei valori? Posso vedere che Moq ha affermato metodi, dovrebbero essere usati nel metodo di test (sembra improbabile dal momento che il documento è memorizzato in una proprietà privata)? Se deve essere usato nei metodi get / set, deve restituire un valore booleano invece del valore effettivo - il che significa che a un certo punto l'intero metodo dovrebbe essere modificato?

Infine, ad un certo punto, avresti sicuramente bisogno di rimuovere tutte le cose Moq e sostituirle con un'implementazione reale? Ma allora questo non significa che i test unitari non possano o non debbano essere usati?

tdd unit-testing mocking

posta binks 13.11.2014 - 16:23

fonte

3 risposte

Leggi altre domande sui tag tdd unit-testing mocking

Quando è utile vale la pena? Scala e gestione delle eccezioni [chiuso]

score 7 · Answer 1

Perché colpire un database è lento, richiede un ambiente elaborato impostato giusto per funzionare e passa la maggior parte del tempo in codice non scritto da te. Un test unitario dovrebbe testare il tuo codice, non il codice Oracle.

2./3. No, non sostituisci le cose derise con cose reali. Lascerai i collaboratori derisi nel tuo codice di test, quindi non invierai il codice di test al cliente . Spedisci solo il tuo codice commerciale.

All'inizio può sembrare un orribile spreco avere enormi quantità di codice che non vengono nemmeno consegnate a nessuno, ma non lo è. Fidati di me. Il punto di test è migliorare la qualità del codice aziendale e una suite di test ampia e ben gestita ottiene esattamente ciò, anche se non vede mai la luce del giorno. Consideralo come parte del tuo set di strumenti piuttosto che parte del prodotto: un fornaio vende ciambelle, non vende il suo forno.

score 5 · Answer 2

Quando stai testando un'unità di codice (ad esempio un singolo metodo o una classe), vuoi solo testare quell'unità e non avere altre dipendenze (con uno stato probabilmente sconosciuto).

Se non usi i mock nei test unitari, ti stai mettendo in una posizione di incertezza - se una classe il tuo metodo / classe dipende dalle modifiche, può interrompere il test anche se il tuo codice non è cambiato .

Questo è particolarmente vero per i test che dipendono da IO (disco, rete, DB), poiché potrebbero non funzionare per ragioni che non hanno nulla a che fare con il software: aumenti della latenza, congestione della rete, modifiche ai dati nel database. .

Ancora: i test unitari riguardano il test di un'unità . In isolamento.

Lastly, at some point you would surely need to remove all the Moq stuff and replace it with a real implementation?

Um. No. Non in te test di unità . Certo, nella tua base di codice attuale, dove usi la classe / metodo, le passerai le sue dipendenze reali, ma nel tuo codice di test? Usa sempre i mock.

Ora per la domanda di implementazione:

If its supposed to be used in the get/set methods, then they must return a Boolean instead of the actual value - which means at some point the whole method would need to be changed??

Eh? Se stai andando a testare con i metodi get / set, assicurati che restituiscano ciò che dovrebbero. Nel tuo test, le tue affermazioni stanno verificando che ciò che viene restituito è corretto - non che ciò che viene restituito è un booleano.

score 1 · Answer 3

Qual è l'idea alla base del mocking dell'accesso ai dati nei test unitari ?

-

La velocità dei test.

È certamente vero che non è necessario testare il database, il file system o altre dipendenze esterne, ma in realtà spesso non è così difficile impostare il database, ecc. e il codice effettivamente funziona in modo tale che sia davvero facile da usare il database ed è il più vicino al mondo reale.
Scrivere un intero gruppo di test che hanno il mocking e lo stub solo per testare "solo il tuo codice" con una separazione di preoccupazioni è un principio elevato, ma non uno che generalmente giustifica la spesa per farlo effettivamente.

Tranne una piccola cosa.

Velocità.

-

C'è anche un altro componente chiave da considerare in quest'area:

Test di integrazione

Questi test, ad esempio i test automatizzati di browser ui, testano davvero l'intero stack e quindi sono ottimali per garantire che, con connessioni di database reali, l'applicazione funzioni davvero come desiderato.

L'uso dei test di integrazione è un componente chiave per essere a proprio agio con il mocking e lo stub nei test unitari.

I test, centinaia e migliaia di essi, che accedono al database saranno lenti. Ad esempio, nel framework che conosco meglio - Ruby on Rails - un test che crea e utilizza diversi oggetti di database (tramite record attivo) può richiedere diversi millisecondi. Il codice sotto test però potrebbe richiedere meno di 100 millisecondi. In definitiva questo può portare a test suite che richiedono ore anziché minuti o secondi. Una suite di test in esecuzione rapida è la chiave per lo sviluppo rapido e moderno e quindi questo fattore è fondamentale.

Test fumo / volume / prestazioni

Potrebbero anche esserci test del fumo, test del volume e test delle prestazioni che esercitano anche lo stack completo e forniscono copertura per il derisione e lo stub nei test unitari.