asserzione: presuppongono il fallimento, o assumere il successo

Question

Durante la prova in qualsiasi lingua, come fa ognuno frase i loro messaggi di asserzione?

Vedo tre modi ovvi:

# assume failure 
assert (4-2) == 2, "Subtracting 2 from 4 doesn't equal 2" 

# describe success 
assert (4-2) == 2, "Subtracting 2 from 4 should equal 2" 

# be vauge with failure 
assert (4-2) == 2, "Subtracting 2 from 4 is broken" 

Si tratta ovviamente di un esempio semplice, ma si ottiene l'idea. Qual è la pratica standard? cosa fai? Perché?

Answer 1

La cosa importante con un'asserzione è la condizione attuale in fase di test. In C è possibile utilizzare il preprocessore "stringization" per l'uscita la reale condizione in fase di test. Il mio codice genera solo

Assert Failed: (4-2)==2 : Line 123, File foo.c 

Se siete fortunati, è possibile ottenere un dump dello stack così ...

Answer 2

E 'davvero non importa IMO, a patto che il messaggio di errore vi dice che cosa è andato sbagliato e dove il problema è In condizioni normali, un messaggio di asserzione non verrà mai visto. Se si è visto, c'è un bug nel codice da qualche parte, e avete bisogno di essere in grado di rintracciare e correggere il bug.

Il messaggio dovrebbe fornire quante più informazioni utili possibili - se stai verificando che due valori sono uguali e non lo sono, dovresti stampare quali sono i valori. Ciò evita la necessità di intervenire con un debugger per esaminare i valori. Ovviamente, ciò richiede che la tua lingua supporti le informazioni non statiche nei messaggi di asserzione. Se i messaggi di asserzione può essere risolto solo, stringhe statiche, non è possibile aggiungere informazioni di runtime extra senza i salti mortali.

Answer 3

Non so qual è la pratica standard, ma combino i primi due approcci con l'aggiunta del risultato effettivo ottenuto.

 
"Substracting 2 from 4 should equal 2, but equals " + value 

Questo non lascia spazio a dubbi e facilita il debug.

Answer 4

Il suggerimento di Roddy è buono - certamente rende il "costo" di aggiungere nuove asserzioni molto meno costose (cioè non richiede di pensare o digitare un nuovo messaggio di stringa). Che ci crediate o no, ma il suo suggerimento attuazione ha avuto un impatto significativo sul mio utilizzo di asserzioni.

Se siete ancora alla ricerca di un messaggio di testo più chiaro, però, si potrebbe prendere in considerazione qualcosa di simile:

"Expected 4-2 per uguagliare 2"

Questo sembra mettere in chiaro (almeno per me) che la risposta prevista era 2, ma che l'aspettativa non era soddisfatta ...

Answer 5

Non so se c'è uno "standard", ma nella maggior parte dei casi mi piace vedere la condizione di affermazione stessa. C lo fa automaticamente. In C# devo copiare e incollare, sfortunatamente, ad es.

Debug.Assert(4-2==2, "4-2==2");

In alcuni casi è utile per visualizzare ulteriori informazioni rispetto alla condizione fornisce. In tal caso tratta il messaggio di asser come un messaggio di errore e dichiaro cosa non va, ad es.

Debug.Assert(result != null, "No result returned for input '" + input + "'");

Answer 6

Io uso il messaggio asserzione documento ciò che l'affermazione è di prova, o ciò che il valore atteso è di circa.

A volte, quando un test fallisce, non ho bisogno di guardare il test fallito: solo dal messaggio di asserzione e dai cambiamenti che ho appena fatto, so come risolverlo.

Answer 7

Trattiamo messaggi di asserzione come commenti: cerco di non averli se posso evitarlo, se riesco a chiarire l'intento dal codice.

Di solito questo è un problema quando ci sono diversi attributi su cui si vuole affermare che sono correlati in qualche modo. Estrarre le asserzioni in un metodo chiamato per indicare l'aspetto/relazione che ti interessa rende più ovvio cosa sta succedendo senza il costo di mantenere il commento/messaggio.