¿Necesitamos iniciar sesión cuando hacemos TDD?

40

Al hacer el rojo, verde y amp; Ciclo de refactor siempre debemos escribir el código mínimo para pasar la prueba. Esta es la forma en que me enseñaron sobre TDD y la forma en que casi todos los libros describen el proceso.

Pero ¿qué pasa con el registro?

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

Así que mis preguntas son:

  1. ¿Necesitamos iniciar sesión si estamos haciendo TDD? no será una prueba de prueba que falla ¿Qué pasa con la aplicación?
  2. ¿Deberíamos agregar pruebas para el proceso de registro en cada método en cada clase?
  3. Si, por ejemplo, algunos niveles de registro están deshabilitados en el entorno de producción, ¿no introducirá eso 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 que falla.

¿Hay algo que me esté perdiendo?

    
pregunta Songo 24.02.2014 - 14:05

9 respuestas

49
  

1) ¿Necesitamos iniciar sesión si estamos haciendo TDD? ¿Una prueba fallida no revelará qué falla con la aplicación?

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

  

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

Si se prueba el registrador, no será necesario volver a realizar la prueba en cada clase, de manera similar a otras dependencias.

  

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

Los humanos (y los agregadores de registros) dependen de los registros, las pruebas no deben depender de ellos. Normalmente, hay varios niveles de registro, y algunos se usan en producción, y algunos niveles adicionales se usan en desarrollo, similar a:

"El nivel de registro de Rails es información en modo de producción y depuración en desarrollo y prueba" - enlace

Otras aplicaciones utilizan un enfoque similar.

  

4) La gente habla de 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.

    
respondido por el FMJaguar 24.02.2014 - 14:27
34

Logging es útil para explicar 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 un pista de auditoría que se puede utilizar para comprender la actividad del sistema y para 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 servidor aplicaciones) ...

No importa cómo se probó la aplicación y sin importar qué tan bien se registran las excepciones, sus usuarios pueden preguntar,

  

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

Necesita registro 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 en el desarrollo. Después de que la aplicación entre en funcionamiento, es conveniente dejar que alguien más 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 investigar el código y sin distraer a los desarrolladores con solicitudes para explicar lo que está sucediendo.

    
respondido por el gnat 24.02.2014 - 14:40
16

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 indicar por qué es lento. Incluso con una cobertura de prueba completa de todos los aspectos, una serie de pruebas no lo dirá.

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

    
respondido por el johannes 24.02.2014 - 14:46
8

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 puede ayudar a comprender qué es lo que está mal cuando, inevitablemente, las cosas salen mal.

El registro y TDD abordan diferentes problemas.

    
respondido por el Andres F. 24.02.2014 - 14:39
7
  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á (EDIT: y, como se dice en los comentarios, incluso si lo hace, algo independiente de su software podría causar un fallo); es lo mismo que pensar que puedes hacer un software que no tenga absolutamente ningún error (ni siquiera la NASA puede hacer esto). Por lo menos, necesita registrar posibles fallos en caso de que su programa se bloquee para que pueda saber por qué.

  2. El registro debe ser realizado por una biblioteca externa o un marco interno en función de la tecnología que esté utilizando. Lo que quiero decir con eso es que debe ser algo que ya se ha probado antes y que no es necesario que se haga la prueba usted mismo. Es excesivo probar que todos los métodos registran las cosas que se supone que deben hacer.

  3. Los registros no están diseñados para pruebas, no debe haber dependencia alguna. Dicho esto, no necesita deshabilitar el registro para las pruebas si le parece una restricción, aunque los registros deben guardarse 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 lo que salió mal cuando falló una prueba de TDD. Los registros deben 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 única del algoritmo que lo ayude a detectar dónde se encuentra realmente el problema.

respondido por el Pierre Arlaud 24.02.2014 - 14:32
5

Sí, en el caso general necesita registro.

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

Pero la parte más importante del registro es la facilidad de mantenimiento. Un registro bien diseñado podría responder a las siguientes preguntas:

  • ¿La aplicación sigue viva y dando patadas? (Al registrar un latido del corazón 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 ocurriendo?

Todo esto se puede lograr mediante el registro. Y sí, debería ser planificado, diseñado y probado, preferiblemente automático.

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

    
respondido por el Jens Schauder 24.02.2014 - 19:39
4

TL; DR: el registro y el TDD son ortogonales. Tener uno no tiene que ver con necesitar el otro

  

¿Necesitamos iniciar sesión si estamos haciendo TDD? ¿Una prueba fallida no revelará qué falla con la aplicación?

En general, la mayoría de los registros que he implementado y que he visto implementados han sido para la solució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 quieren mirar los registros e intentar averiguar qué está pasando.

Estos registros están ahí para ayudar a solucionar problemas que afectan en gran medida a los puntos de integración. Esto puede ser servicios de red (base de datos, soap, etc.), recursos locales (disco, memoria, etc.), datos incorrectos (entrada del cliente, fuentes de datos incorrectos / corruptos, etc.), etc. (configuraciones, configuraciones, etc.) pueden ayudar a resolver problemas.

  

¿Deberíamos agregar pruebas 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 sesión, debe probarlas. Aunque si implementa el registro y las pruebas de registro utilizando Programación Orientada a Aspectos o una meta programación, eso puede reducir la carga de la prueba.

  

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

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

    
respondido por el dietbuddha 26.02.2014 - 09:24
3

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

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

    
respondido por el JohnB 24.02.2014 - 15:00
2

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

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

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

El ejemplo podría ser los 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 hace cálculos complejos. Puede ser muy útil tener figuras que ingresen al método (por ejemplo, puede escribir una prueba de unidad para volver al tema general en cuestión).

    
respondido por el dbalakirev 26.02.2014 - 08:28

Lea otras preguntas en las etiquetas