Uso ASSERT estándar/Q_ASSERT, pero cuidado con las afirmaciones "no válido", especialmente si deja tales diagnósticos en pruebas externas (compilación sin NDEBUG).
Pequeña historia sobre la implementación de DBC (utilizando aserciones) en un proyecto de C++ y la política de "depuración siempre habilitada".
Estábamos usando herramientas bastante estándar (ASSERT()/Q_ASSERT()) como implementación DBC hasta que llegamos a la siguiente situación en las pruebas de integración: nuestra última compilación siempre falla después de iniciar. No fue muy profesional lanzar dicha versión (después de la semana de esfuerzos internos de control de calidad).
¿Cómo se presentó el problema?
- Un desarrollador izquierda afirmación equivocada (expresión lógica no válida) en el código fuente
- Toda nuestra compilación anterior tenían afirmaciones habilitadas (para rastrear errores en las pruebas de integración)
- de control de calidad interno tiene diferentes configuraciones de entorno que las pruebas de integración, por lo que el "error de aserción" no era visible
Como resultado poo r se culpó al desarrollador de por este error (obviamente sin este ASSERT no habría bloqueo) y tuvimos que lanzar el hotfix para permitir que continuaran las pruebas de integración.
En primer lugar: Necesito afirmaciones habilitadas en las pruebas de integración para rastrear las condiciones fallidos (las afirmaciones más mejor), por otra parte, que no quiero a los desarrolladores tengan miedo de que algunos afirman "extra" bloqueará la pila completa de software.
Encontré, probablemente interesante resolución basada en C++ para este problema: aserciones débiles. La idea es para no detener la aplicación completa en la aserción fallida, pero para registrar stacktrace para un análisis posterior y continuar. Podemos verificar todas las expectativas que queramos sin temor a bloqueos y obtenemos retroalimentación (stacktraces) de la integración. La ejecución de un solo proceso puede proporcionar muchos casos de aserción fallida para análisis en lugar de solo uno (porque no se llama a abort()).
La aplicación de esta idea (con un poco de magia LD_PRELOAD) se describe brevemente aquí: http://blog.aplikacja.info/2011/10/assert-to-abort-or-not-to-abort-thats-the-question/
Debe aclarar qué lo deja insatisfecho con los mecanismos simples con la macro assert (minúsculas). –
Ver también http://stackoverflow.com/questions/179723/what-is-the-best-way-of-implementing-assertion-checking-in-c –
Acabas de vincular a una biblioteca que hace exactamente lo que eres preguntando por. ¿Qué esperas que digamos? "¿Podría darle una oportunidad a http://www.codeproject.com/KB/cpp/DesignByContract.aspx"? Si quieres algo más de lo que ofrece esa biblioteca, entonces no lo uses como un ejemplo de lo que estás buscando. Cuéntanos lo que quieres que no brinde. – jalf