¿Necesitamos iniciar sesión cuando hacemos TDD?

Al hacer el ciclo Rojo, Verde y Refactor, siempre debemos escribir el código mínimo para pasar la prueba. Esta es la forma en que me han enseñado sobre TDD y la forma en que casi todos los libros describen el proceso.

¿Pero qué pasa con la tala?

Honestamente, rara vez he usado el inicio de sesión en una aplicación a menos que haya algo realmente complicado que esté sucediendo, sin embargo, he visto numerosas publicaciones que hablan sobre la importancia de un registro adecuado.
Entonces, aparte de registrar una excepción, no podría justificar la importancia real de iniciar sesión en una aplicación probada adecuada (pruebas de unidad / integración / aceptación).

Entonces mis preguntas son:

1. ¿Necesitamos iniciar sesión si estamos haciendo TDD? ¿No revelará una prueba que falla qué está mal con la aplicación?
2. ¿Deberíamos agregar una prueba para el proceso de registro en cada método en cada clase?
3. Si algunos niveles de registro están deshabilitados en el entorno de producción, por ejemplo, ¿eso no introducirá una dependencia entre las pruebas y el entorno?
4. La gente habla sobre cómo los registros facilitan la depuración, pero una de las principales ventajas de TDD es que siempre sé lo que está mal debido a una prueba fallida.

¿Hay algo que me estoy perdiendo por ahí?

1) ¿Necesitamos iniciar sesión si estamos haciendo TDD? ¿No revelará una prueba que falla qué está mal con la aplicación?

Eso supone que tiene todas las pruebas posibles que su aplicación necesita, lo cual rara vez es cierto. Los registros lo ayudan a localizar errores para los que aún no escribió pruebas.

2) ¿Deberíamos agregar una prueba para el proceso de registro en cada método en cada clase?

Si se prueba el registrador en sí, no será necesario volver a probarlo en cada clase, de forma similar a otras dependencias.

3) Si algunos niveles de registro están deshabilitados en el entorno de producción, por ejemplo, ¿eso no introducirá una dependencia entre las pruebas y el entorno?

Los humanos (y los agregadores de registros) dependen de los registros, las pruebas no deberían depender de ellos. Por lo general, hay varios niveles de registro, y algunos se usan en producción, y algunos niveles adicionales se usan en desarrollo, de forma similar a:

"El nivel de registro de Rails es información en modo de producción y depuración en desarrollo y prueba" - http://guides.rubyonrails.org/debugging_rails_applications.html

Otras aplicaciones utilizan un enfoque similar.

4) La gente habla sobre cómo los registros facilitan la depuración, pero una de las principales ventajas de TDD es que siempre sé lo que está mal debido a una prueba fallida.

Los errores de producción habrán pasado todas las pruebas, por lo que es posible que necesite alguna otra referencia para investigar esos problemas.

El registro es útil para explicar el comportamiento no excepcional de una aplicación:

Los registros de eventos registran los eventos que tienen lugar en la ejecución de un sistema para proporcionar una pista de auditoría que se puede utilizar para comprender la actividad del sistema y diagnosticar problemas. Son esenciales para comprender las actividades de los sistemas complejos, particularmente en el caso de aplicaciones con poca interacción del usuario (como las aplicaciones de servidor ) ...

No importa cómo se haya probado la aplicación y no importa qué tan bien se registren las excepciones, sus usuarios pueden preguntar,

la salida de su programa es 0 mientras esperábamos que fuera 1, ¿por qué es eso?

Necesita iniciar sesión para verificar qué era la configuración de la aplicación, los parámetros y otros detalles de tiempo de ejecución para explicar su comportamiento (no excepcional).

Desde la perspectiva anterior, el registro está más orientado al soporte que al desarrollo. Después de que la aplicación se active, es deseable dejar que otra persona maneje las preguntas de los usuarios, para permitir que los programadores se centren en un mayor desarrollo.

El registro de lo que hace la aplicación permite que otra persona entienda el comportamiento del programa sin profundizar en el código y sin distraer a los desarrolladores con solicitudes para explicar qué está sucediendo.

La mayoría de las respuestas aquí se centran en el aspecto de la corrección. Pero el registro también tiene un propósito diferente: el registro puede ser una forma de recopilar datos relevantes de rendimiento. Entonces, incluso cuando el sistema funciona sin errores, un registro puede decir por qué es lento. Incluso con una cobertura de prueba completa de todos los aspectos, un conjunto de pruebas no lo dirá.

Por supuesto, un sistema crítico de rendimiento puede / debe proporcionar métricas clave de rendimiento a algunos paneles operativos, pero el registro "clásico" puede proporcionar un nivel de detalle diferente.

1. A menos que tenga una cobertura de prueba del 100%, que generalmente no es el caso, no puede saber que su software nunca se bloqueará (EDITAR: y, como se dice en los comentarios, incluso si lo hace, algo independiente de su software podría causar un choque); es lo mismo que pensar que puedes hacer un software que no tiene absolutamente ningún error (ni siquiera la NASA puede hacer esto). Por lo menos, debe registrar posibles fallas en caso de que su programa se bloquee para que pueda saber por qué.

2. El registro debe realizarlo una biblioteca externa o un marco interno, según la tecnología que esté utilizando. Lo que quiero decir con eso es que debería ser algo que ya se haya probado antes y que no es necesario que te hagas la prueba. Es excesivo probar que cada método registra las cosas que se supone que debe hacer.

3. Los registros no están destinados a pruebas, no debería haber dependencia alguna. Dicho esto, no necesita deshabilitar el registro para las pruebas si le parece una limitación, aunque los registros deben mantenerse en un archivo correspondiente al entorno (debe tener un archivo diferente para el entorno de prueba, desarrollo y producción). por lo menos).

4. Un error puede ser muy poco claro y no siempre es obvio qué salió mal cuando falló una prueba TDD. Los registros deberían ser más precisos. Por ejemplo, si está haciendo un algoritmo de clasificación y falla todo el caso de prueba, debe tener registros para cada prueba del algoritmo que lo ayuden a detectar dónde se encuentra realmente el problema.

La respuesta corta a su pregunta principal es: como regla general, los errores en su código NO serán expuestos por TDD. Algunos podrían, idealmente muchos, pero la ausencia de pruebas fallidas no implica la ausencia de errores. Esta es una máxima muy importante en las pruebas de software.

Dado que no puede saber si tendrá un comportamiento incorrecto en su sistema, tal vez en condiciones excepcionales, el registro es una herramienta útil que podría ayudar a comprender qué está mal cuando las cosas inevitablemente salen mal.

El registro y TDD abordan diferentes preocupaciones.

Sí, en el caso general, necesita iniciar sesión.

El registro no se trata de depuración. Bueno, está bien, una parte del registro a veces se trata de depuración, y puede omitir esa parte si no la necesita durante el desarrollo.

Pero la parte más importante del registro es la mantenibilidad. El registro bien diseñado puede responder las siguientes preguntas:

• ¿La aplicación sigue viva y coleando? (Al registrar un latido cada 1000 segundos).
• ¿Cambió el rendimiento de la aplicación en los últimos 10 meses? (Al registrar estadísticas del rendimiento de los casos de uso).
• ¿Cambió la carga de la aplicación en los últimos 10 meses? (Al registrar el número de solicitudes por tipo de solicitud).
• ¿Alguna de nuestras interfaces cambió sus características de rendimiento?
• ¿La nueva versión causa una característica de uso diferente hacia algunos de los subsistemas?
• ¿Estamos bajo un ataque DoS ?
• ¿Qué tipo de errores están sucediendo?

Todo esto se puede lograr mediante el inicio de sesión. Y sí, debe planificarse, diseñarse y probarse, preferiblemente de forma automática.

El registro es una característica que merece tratamiento, al igual que otras características.

TL; DR: el registro y TDD son ortogonales. Tener uno no tiene relación con la necesidad del otro

¿Necesitamos iniciar sesión si estamos haciendo TDD? ¿No revelará una prueba que falla qué está mal con la aplicación?

En general, la mayoría de los registros que he implementado y que he visto implementados han sido para la resolución de problemas operativos, no para la depuración del desarrollo (aunque puede ayudar). La audiencia principal para este registro son los administradores y las operaciones que ejecutan sus servidores, apoyan a las personas que tienen registros enviados para su análisis, y los clientes que desean ver los registros e intentar averiguar qué está sucediendo.

Estos registros están ahí para ayudar a solucionar problemas que afectan en gran medida a los puntos de integración. Esto puede incluir servicios de red (base de datos, jabones, etc.), recursos locales (disco, memoria, etc.), datos incorrectos (entrada del cliente, fuentes de datos defectuosas / corruptas, etc.), etc. Capturando excepciones, registrando fallas e incluso realizando registros informativos. (configuraciones, configuraciones, etc.) pueden ayudar con la resolución de problemas.

¿Deberíamos agregar una prueba para el proceso de registro en cada método en cada clase?

Agregue pruebas donde sea necesario para probar el registro. Si tiene llamadas ad hoc para cerrar la información, entonces deben probarse. Aunque si implementa el registro y las pruebas de registro utilizando la Programación Orientada a Aspectos o la meta programación, eso puede reducir la carga de las pruebas.

Si algunos niveles de registro están deshabilitados en el entorno de producción, por ejemplo, ¿eso no introducirá una dependencia entre las pruebas y el entorno?

Si está escribiendo su código utilizando IoC y utiliza simulacros, debería poder probar de manera efectiva todos sus registros sin depender de una configuración ambiental particular.

TDD generalmente ayuda a reducir errores de codificación. Ayuda mucho menos con errores con la especificación o simplemente malentendidos sobre cómo funcionan las cosas.

"¿Oh? ¿Puedes recibir un mensaje de datos antes de obtener la confirmación de que el inicio de sesión se realizó correctamente? ¡Nunca lo supe, bueno, eso no lo manejará!" ... Ese tipo de cosas. El registro es muy útil para decirle lo que el software intentó hacer para que pueda detectar lo que hizo mal.

En mi experiencia, se agrega un gran nivel de registro a la aplicación cuando no hacemos TDD. Luego, el nivel de incertidumbre se vuelve alto, por lo tanto, agregamos registros para ver qué está pasando.

Mientras que cuando hago TDD (o tal vez prueba cuando sea) me encuentro agregando muchas menos declaraciones de registro. Esto a su vez significa menos LOC y puede (no siempre) afectar el rendimiento.

Pero en la mayoría de los casos, agregamos registros de entrada y salida para funciones de forma semiautomática en mi empresa, independientemente del método de desarrollo. Como sé, esto se consideró obligatorio para el análisis de problemas de producción.

Los ejemplos podrían ser métodos de un bean de servicio EJB que están presentes en la interfaz pública. Otro podría ser un caso cuando una función realiza cálculos complejos. Puede ser de gran ayuda tener cifras que ingresen al método (por ejemplo, puede escribir una prueba unitaria para volver al tema general en cuestión).