Assert.that vs Assert.True

Question

Cosa preferisce:

Assert.That(obj.Foo, Is.EqualTo(true)) 

o

Assert.True(obj.Foo) 

Per me, entrambi afferma sono equivalenti, in modo che dovrebbe essere preferiva?

Answer 1

In questo caso particolare, non vi è alcuna differenza: vedrete l'output approssimativamente dello stesso livello di dettaglio (cioè vi dirà che qualcosa che ci si aspettava di valutare a true è stato valutato a false). Lo stesso vale per

Assert.IsTrue(obj.Foo); 

e

Assert.That(obj.Foo, Is.True); 

tua squadra dovrebbe scegliere uno stile di asserzioni, e bastone con esso in tutti i test. Se la tua squadra preferisce lo stile Assert.That, allora dovresti usare Assert.That(obj.Foo, Is.True).

Answer 2

Questo è un po 'pignolo ma IMHO penso che in questo caso Assert.That sia inutilmente prolisso e possa quindi essere considerato come offuscamento. In altre parole, Assert.True è un po 'più pulito, più semplice e più facile da leggere e quindi da comprendere.

Per ottenere un po 'più pignoli esigente Io suggerirei di usare il Assert.IsTrue API invece di Assert.True in quanto, ancora una volta secondo la mia opinione, IsTrue "legge" meglio.

Answer 3

Quindi ok, hai eseguito la tua suite di test sul server CI e, sfortunatamente, uno di loro non è riuscito. Si apre i registri e vedere messaggio successivo

BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false 

Ora come diavolo vuoi ottenere quello che è successo di sbagliato in questo test, se tutte le informazioni che si vede, è che da qualche parte nel AutoLoginTests bool era previsto vera, ma ricevuto falso? Ora devi andare al file sorgente dei tuoi casi di test e vedere, quale asserzione fallita. Si vede

Assert.True(obj.Foo) 

Sorprendentemente .. è ancora difficile dire cosa c'è di sbagliato, solo se avete sviluppato questo modulo 1 giorno fa. Devi ancora approfondire le fonti dei test e probabilmente anche le fonti di produzione o persino eseguire il debug del codice, in modo che tu possa finalmente capire che hai sbagliato a digitare una variabile all'interno della chiamata di funzione o utilizzato un predicato errato per filtrare gli utenti registrati. Così hai bloccato il feedback immediato dai test, che è molto prezioso.

Il mio punto è che non importa quanto siano fluenti le proprie asserzioni (che sono anche rilevanti), ma quali informazioni si espongono in caso di test falliti e quanto velocemente si può ottenere il sottostante motivo del fallimento, anche se si ha funzionato molto tempo fa con questo functionaluty

Answer 4

Assert.That è chiamato il modello basato su vincoli. È flessibile perché il metodo utilizza un parametro del tipo IConstraint. Ciò significa che puoi strutturare il tuo codice con una gerarchia più generica o una struttura di chiamata, passando in qualsiasi vecchio IConstraint. Significa che è possibile creare il proprio custom constraints

Questo è un problema di progettazione. Come tutti stanno dicendo, non importa ciò che è ancora necessario fornire un feedback decente dei messaggi di errore.