Cómo decidir qué forma el sistema bajo prueba

7

Bien, entonces comenzamos con la versión inicial de "The Art Of Unit Testing" y realizamos pruebas unitarias para clases en las que cada prueba cubre un aspecto de un método.

Esto tiene el inconveniente de los altos costos de mantenimiento y las pruebas de fragilidad y parece que la segunda versión de "The Art Of Unit Testing" apunta a tomar unidades más grandes al realizar pruebas.

¿Cuál es el tamaño correcto (el que usas) cuando haces pruebas de unidad? He oído hablar de pruebas solo de la interfaz pública provista por un módulo, pero en el proyecto en el que estamos trabajando tenemos una superficie pública relativamente pequeña con una oficina administrativa muy grande, por lo que no estoy seguro de si eso funcionará como el Arreglo de las pruebas Sería realmente grande y probablemente difícil de seguir.

Entonces, nuevamente, ¿cómo se establecen los límites de su SUT o cómo decide qué forma su SUT?

    
pregunta Ignacio Soler Garcia 01.06.2015 - 17:15

2 respuestas

3

Idealmente, las cosas variarían de acuerdo con la regla del sentido común. Martin Fowler habla de una unidad como una clase (más clases relacionadas en algunos casos) y, en mi humilde opinión, una unidad debería ser un bloque de código útil, este puede ser un método único en el que un método es bastante complejo, o una clase completa como clases Los medios de dividir un sistema en componentes manejables.

Un solo método generalmente no es una unidad, ya que tienden a ser demasiado granulares para ser de algún uso práctico.

Tal vez una regla de oro es pensar en la prueba como documentación: puede usar sus pruebas como código de ejemplo, y cómo usar una pieza de funcionalidad. Si piensa que una prueba no tiene sentido para nadie más, ya que las pruebas son demasiado pequeñas o triviales, es un olor que la unidad que se está probando también sea demasiado pequeña y debe incluirse en una unidad más amplia. Por lo tanto, un método complejo puede requerir una gran cantidad de entradas posibles, y su prueba las demostrará, pero una clase de red (por ejemplo) tendrá una prueba que describa a toda la clase al construirla, establecer el nombre de host y el puerto, y luego llamar a enviar o recibir Métodos en él: esos métodos por sí mismos son inútiles por sí mismos.

Sólo tiene sentido probar la interfaz pública: si la interfaz pública no puede acceder al código, ¡entonces no hay ninguna razón real para tenerlo! Sin embargo, usted dice que tiene una gran funcionalidad de back-office, la API para acceder a las partes componentes del back-office sigue siendo una interfaz pública (es decir, es pública para un cliente o clase de computadora) y debe considerarse para una prueba de unidad en A ese respecto.

    
respondido por el gbjbaanb 01.06.2015 - 17:52
3

No hay una respuesta de "talla única para todos" en la que debe colocar los límites de su SUT.

El tamaño óptimo de un SUT para pruebas de unidad depende de muchos factores, entre ellos,

  • El idioma y la cadena de herramientas con la que está trabajando (cuántos errores pueden detectarse mediante el análisis estático / compilando el código)
  • La complejidad del producto que está haciendo
  • Qué tan familiar está el equipo con la creación de dicho producto

Un equipo que escribe su décimo sitio web de baja complejidad puede usar SUT mucho más grandes en sus pruebas unitarias que un equipo que es nuevo en el trabajo y / o tiene una tarea con un sitio muy complejo.

Elegir el tamaño de su SUT es un acto de equilibrio. Si es demasiado pequeño, entonces las pruebas comienzan a depender de las opciones de implementación, lo que provoca que se vuelvan a realizar las pruebas si la implementación cambia.
Si es demasiado grande, entonces no hay una correlación fácil entre "La prueba A falla" y "Hay un problema en la función / área B".

Algunas pautas generales son:

  1. Las pruebas son un cliente de una clase, al igual que los otros módulos que eventualmente se conectarán con ella. Los casos de prueba no deben tener acceso a los elementos internos de una clase a menos que sea absolutamente necesario para verificar que se ha cumplido un requisito en particular. E incluso entonces, primero debería ver si ese requisito se puede verificar utilizando solo a los miembros públicos de la clase.

  2. Cada prueba debe verificar un solo requisito. A menudo, esto se tergiversa al tener una sola afirmación en una prueba. Muy a menudo, los requisitos no se pueden verificar con una sola declaración de aserción, lo que lleva a que las personas escriban varios casos de prueba donde cada prueba cubre solo parte de la verificación. Si necesita varias declaraciones de aserción estrechamente relacionadas para verificar un requisito, entonces está perfectamente bien tenerlo todo en una sola prueba.

  3. Debería burlarse de todas las dependencias de su SUT, a menos que se sepa que sean rápidas y bien probadas (como las clases estándar o de terceros). Al escribir las expectativas para estos simulacros, trate de no confiar en el orden en que se realizan las llamadas, a menos que el orden de las llamadas sea un requisito explícito.

  4. Concentre su esfuerzo de prueba en las áreas con alta complejidad y / o incertidumbre. Hay muy poco valor en escribir una prueba para un captador de una línea. Para esas funciones, es muy fácil ver que son correctas y hay poco riesgo de que un cambio futuro las rompa.

respondido por el Bart van Ingen Schenau 01.06.2015 - 18:11

Lea otras preguntas en las etiquetas