Quindi vedo che Assert ha dozzine di metodi che sembrano fare essenzialmente la stessa cosa.Perché la classe "Assert" ha così tanti metodi apparentemente ridondanti? Quando dovrebbero essere usati ciascuno?
Assert.IsFalse( a == b);
Assert.IsTrue( a != b);
Assert.AreNotEqual(a, b);
Perché? È solo per essere più esplicito? Quando dovrebbero essere usati i vari metodi? Esiste un documento ufficiale sulle migliori pratiche?
La differenza tra IsFalse e IsTrue è la leggibilità. AreNotEqual consente di presentare un messaggio di errore migliore quando il test fallisce. Per esempio, IsTrue ti dirò che la risposta doveva essere vera ed era veramente falsa. AreNotEqual mostrerà i due valori che sono stati confrontati nel suo messaggio di errore.
Risposta breve: per la leggibilità.
risposta Leggermente più lungo:
i test sono anche il codice, e in termini di intenti sono importanti quanto il codice si esegue il test. In quanto tale, si desidera rendere l'intento del test il più chiaro possibile. A volte questo significa che usi IsFalse, a volte significa usare IsTrue.
"Tu [r] test sono anche codice ... vuoi rendere l'intento del test più chiaro possibile" ... per giocare ai diavoli avvocato: Allora perché non è pratica standard creare e utilizzare isEqual, isNotEqual, ecc nel codice normale? (Sono consapevole che Equals esiste, ma è usato meno frequentemente) – Catskul
@Catskul: i test riguardano esclusivamente la manutenibilità. Usiamo == e! = Per l'uguaglianza e la disuguaglianza nel codice normale. Quanto spesso vedi: "if (a == (! B))" invece di "if (a! = B)"? –
@Reed, "! B" potrebbe non avere alcun senso. Asserisce che AFAIK deve sempre ridurre a vero/falso. – Catskul
Questi tre metodi hanno tre diversi obiettivi specifici. L'obiettivo del test è di fornire una chiara verifica e convalida del codice. Utilizzando il metodo più chiaro e specifico possibile, stai rendendo il tuo test il più piccolo possibile, con il significato più specifico e chiaro possibile.
Questo aiuta perché aggiunge chiarezza: è possibile vedere, in particolare, che cosa si suppone fare un test in una natura più dichiarativa, in cui utilizzare lo stesso metodo per più scenari di test, ciascuno con un significato diverso, richiede più comprensione del codice stesso, invece della natura del test.
In questo caso, il terzo è il (solo) un opportuno utilizzare. Tuttavia, se si ha questa situazione, devi utilizzare uno diverso, ad esempio:
Assert.IsTrue(myClass.MethodThatReturnsTrue());
si dovrebbe utilizzare il metodo che fornisce il più chiarezza al vostro obiettivo - se si sta controllando due valori per l'uguaglianza , usa Assert.IsEqual, se stai controllando un booleano per verificare che sia falso, usa Assert.IsFalse. Ciò rende le segnalazioni di errore significative e comprensibili.
Hai affermato (non è un gioco di parole) che fanno cose molto diverse, ma non hanno offerto una spiegazione. – Catskul
@Catskul: ho riformulato - è d'aiuto? –
Si rende gli errori più facili da leggere; usa quello che corrisponde al tuo codice più da vicino.
In questo caso, utilizzare # 3.
Perché è possibile sovraccaricare il == e! =, Ecco perché.
... ed è possibile scrivere il proprio metodo Equals. AFAIK non è chiaro che questi metodi Assert non si basano su tali operatori o sul metodo Equals per quella materia. – Catskul
Si chiama "Interfaccia Fluent" ... e rende le cose più leggibile a parere di molti.
IMO, questa è la risposta migliore/più concisa che ho visto finora. La risposta principale manca che dà un messaggio di errore più informativo. – Catskul
I quadri di asserzione fluenti stanno diventando sempre più popolari proprio perché aumentano la leggibilità. Vedi, ad esempio, gli abbinamenti Hamcrest di JUNit (http://code.google.com/p/hamcrest/wiki/Tutorial) e NUnit's ConstraintModel (http://www.nunit.org/index.php?p=constraintModel&r=2.4 .1). –