I metodi di asserzione JUnit devono essere espressi in positivo o in negativo?

Question

Dovrei essere scrivendo
assertTrue("User logged in", user.isLoggedIn());
o
assertTrue("User is not logged in", user.isLoggedIn());

La prima fornisce una migliore lettura all'interno dei file di origine:
"Affermo che quanto segue è vero:. L'utente loggato"

Il messaggio di errore può essere letta in entrambi i modi: "L'errore è che l'utente è connesso a"
java.lang.AssertionError: User logged in
"C'è un errore nell'affermare che l'utente è connesso"

documentazione JUnit non fornisce una chiara guida a cui dovrebbe essere, tranne che è
"il messaggio di identificazione per il {@link AssertionError}",
E in entrambi i casi, il testo identifica l'essere di prova correre.

Qual è l'utilizzo comune?

Answer 1

ne dite:

assertTrue("User should be logged in", user.isLoggedIn()); 

funziona in due modi.

Answer 2

Bene, si potrebbe anche affermare la propria ipotesi, e quindi come l'ipotesi non regge. Così:

assertTrue("Expected user to be logged it, and wasn't", user.isLoggedIn()); 

Crea messaggi più chiari, ma più lunghi da digitare e leggere.

Answer 3

È necessario includere entrambi i casi. Hai migliori casi di test quando triangoli le tue asserzioni.

Answer 4

Per evitare questa domanda, sempre più spesso utilizzo il metodo assertThat anziché "basso livello" assert *. Infatti, come spiega this article, assertThat ti darà un messaggio di errore molto chiaro in caso di errore.

Answer 5

Si potrebbe utilizzare:

assertTrue("Test if user is logged in", user.isLoggedIn()); 

Quando si esegue questa operazione, si sta verificando che user.isLoggedIn() è vero, non si può davvero dire che utente è connesso o no, non si sa ancora, lo stai solo testando

Answer 6

Interessante, vorrei utilizzare:

assertTrue("user should be logged in", user.isLoggedIn()); 

che mi dice che cosa è stato di questa affermazione previsto.

Penso che la scelta migliore sia quella che hai capito.

Answer 7

strettamente positiva nei tuoi messaggi assert

Usa testo assert positiva come nel primo esempio, o come:

assertTrue("User is logged in", user.isLoggedIn()); 

Le ragioni sono:

• affermazione positiva è più breve
• c'è una condizione asserita che si sta verificando, e molte possibili ragioni, perché è andata male. Non tentare di rilevare la causa, solo dichiarare, quale asserzione ha fallito.
• è più leggibile nel codice. Si consiglia in genere di codificare in espressioni positive, che salvano poche negazioni delle condizioni nella mente del lettore
• è ancora leggibile in tracce di errore, che non dovrebbero essere comprese dall'utente comune, ma da un programmatore, chi finirà comunque nel codice. E anche sysadmin, che non avrebbe avuto accesso al codice, avrebbe fornito all'autore un messaggio di errore completo e il programmatore avrebbe capito, proviene da un'affermazione.

Provare a fornire "tutte le informazioni contestuali" nel messaggio asserito non migliora la situazione, piuttosto crea confusione di informazioni.

Sai, i buoni programmatori eseguono il debug di un codice e forniscono il codice di lavoro e più corto.

Utilizzare i messaggi di asserzione positivi come prima cosa da fare in questa direzione.

L'altra direzione: applicare patch al codice con un numero sempre maggiore di cose non necessarie sta aprendo la strada all'inferno di programmazione.