Mensajes de aserción: suponga un error o asuma el éxito

Question

Al probar en cualquier idioma, ¿cómo todos expresan sus mensajes de aserción?

veo tres maneras obvias:

# 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" 

Obviamente, esto es un ejemplo sencillo, pero se entiende la idea. ¿Cuál es la práctica estándar? ¿Qué haces? ¿Por qué?

Answer 1

Lo importante con una afirmación es la condición real que se está probando. En C puede usar el preprocesador "stringization" para dar salida a la condición real que se está probando. Mi código sólo da salida a

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

Si tiene suerte, puede obtener un volcado de pila, así ...

Answer 2

Realmente no importa la OMI, siempre y cuando el mensaje de error que dice lo que pasó mal y donde está el problema Bajo operación normal, nunca se verá un mensaje de aserción. Si se ve, hay un error en el código en alguna parte, y necesita poder rastrear y corregir el error.

El mensaje debe proporcionar tanta información útil como sea posible; si está comprobando que dos valores son iguales y no lo son, debe imprimir cuáles son los valores. Eso obvia la necesidad de entrar en él con un depurador para examinar los valores. Por supuesto, hacer esto requiere que su idioma admita información no estática en los mensajes de aserción. Si los mensajes de aserción solo se pueden corregir, cadenas estáticas, no se puede agregar información de tiempo de ejecución adicional sin saltar por los aros.

Answer 3

No sé cuál es la práctica estándar, pero combino sus primeros dos enfoques con la adición del resultado real obtenido.

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

Esto no deja lugar a dudas y facilita la depuración.

Answer 4

La sugerencia de Roddy es buena, sin duda hace que el "costo" de agregar nuevas afirmaciones sea mucho más barato (es decir, no requiere pensar o escribir un nuevo mensaje de cadena). Créalo o no, pero la implementación de su sugerencia ha tenido un impacto significativo en mi uso de aserciones.

Si todavía está buscando un mensaje de texto más claro, sin embargo, usted podría considerar algo como:

"esperado 4-2 para igualar 2"

Esto parece dejar claro (al menos a yo) que la respuesta esperada era 2, pero que la expectativa no se cumplió ...

Answer 5

No sé si hay algún "estándar", pero en la mayoría de los casos me gusta ver la condición de aserción en sí. C hace esto automáticamente. En C# tengo que copiarlo y pegarlo, desafortunadamente, ej.

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

En algunos casos es útil para ver más información que proporciona la condición. En ese caso, trato el mensaje afirmar como un mensaje de error y expongo lo que está mal, por ejemplo.

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

Answer 6

uso el mensaje de afirmación a documento lo que la afirmación es la prueba, o lo que el valor esperado se trata.

A veces, cuando falla una prueba, no necesito mirar la prueba que falla: solo por el mensaje de afirmación y los cambios que acabo de hacer, sé cómo solucionarlo.

Answer 7

Trato los mensajes de aserción como los comentarios: trato de no tenerlos si puedo evitarlo, si puedo aclarar la intención del código.

Normalmente, este es un problema cuando hay varios atributos que desea afirmar que están relacionados de alguna manera. La extracción de las aserciones en un método llamado para indicar el aspecto/relación que le interesa hace que sea más obvio lo que está sucediendo sin el costo de mantener el comentario/mensaje.