Come (o dovrei) avere un assert per test con confronti tra oggetti? [duplicare]

Question

Come (o dovrei) avere un assert per test con confronti tra oggetti? [duplicare]

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

2

Recentemente ho letto The Art of Unit Testing di Roy Osherove che ho trovato molto utile per aiutarmi a stabilire come definire una buona unità prova.

Un aspetto chiave delle linee guida proposte da Roy è quello di assicurarsi che un test provi solo una cosa, che è parte delle seguenti linee guida si propone:

Assicurati che il test esegua solo una prova (pagina 179)
Assicurati che il test verifichi solo su una singola chiamata a un oggetto fittizio. La verifica di più chiamate su un oggetto fittizio o supera le specifiche o verifica più cose.

Un buon modo per ottenere questo risultato è un singolo assert in ogni test di unità.

Tuttavia, se il test unitario deve validare il comportamento di un metodo che restituisce un oggetto che ha proprietà specifiche, come può essere verificato con un singolo assert? Sembra che le risposte possibili siano:

No, basta usare più asserzioni per convalidare ogni proprietà prevista dell'oggetto restituito
Sostituisci Object.Equals e Object.GetHashCode (in C #) in modo che i due oggetti possano essere facilmente confrontati.
Utilizza un framework che consente di confrontare due oggetti (ad esempio link in C #)

object-oriented unit-testing c# comparison assertions

posta Peter Bridger 01.05.2014 - 14:46

fonte

2 risposte

Leggi altre domande sui tag object-oriented unit-testing c# comparison assertions

Come essere Agile quando un nuovo lavoro continua a influire sul lavoro completato? Come passare da "aiuto vampiro" a "sviluppatore"? [chiuso]

score 5 · Answer 1

Penso che ci sia troppa ideologia nei test unitari. 1 assert per test è un esempio.

Il test unitario riguarda il test di un'unità, ad esempio una cosa. Quindi se hai una classe con 5 proprietà su di essa, è perfettamente accettabile colpire tutti e 5 i puntelli per vedere se funzionano. Se uno di essi fallisce, il test fallisce.

Non fa differenza tentare di testare ciascuna delle 5 proprietà nei singoli test - se uno di essi fallisce, non ottieni nulla. (Presumo che tu abbia scritto abbastanza informazioni per dire quale asserzione è fallita, e qualche logging o altra diagnostica per capire perché ha fallito). In breve, il tuo oggetto ha fallito e devi aggiustarlo. Se hai bisogno di maggiori dettagli, hai bisogno di molti più dettagli di quelli ottenuti da una singola asserzione comunque.

Quello che non farei è provare a testare molti oggetti in un singolo test.

Trova un punto debole tra troppi test unitari e test unitari troppo grandi.

score 1 · Answer 2

L'altra risposta è una grande risposta pragmatica. Prenderò una posizione diversa, comunque.

Anche se sono d'accordo sul fatto che affermare che una cosa può essere più generale di quanto spesso le persone lo rendano, nella tua situazione specifica hai menzionato la risposta corretta.

.Equals() e .GetHashCode() esistono. Il tuo oggetto li ha. Sono attualmente inutili. Qualsiasi soluzione diversa dall'implementazione lascia un potenziale punto debole in seguito. I confronti tra oggetti sono importanti e possono essere riutilizzati. Inoltre, avere i metodi che chiamate effettivamente fanno cose utili è molto vantaggioso.

Anche se può sembrare uno spreco poiché non hai intenzione di riutilizzarli, questo argomento non si applica a questi due metodi perché sono una parte fondamentale del linguaggio.