¿Es útil para los métodos de prueba unitaria donde la única lógica es la protección?

12

Di que tengo un método como este:

public void OrderNewWidget(Widget widget)
{
   if ((widget.PartNumber > 0) && (widget.PartAvailable))
   {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

Tengo varios métodos de este tipo en mi código (la mitad frontal de una llamada de servicio web asíncrona).

Estoy debatiendo si es útil cubrirlos con pruebas de unidad. Sí, aquí hay lógica, pero solo es lógica de guarda. (Lo que significa que me aseguro de tener lo que necesito antes de permitir que se realice la llamada al servicio web).

Una parte de mí dice "seguro que puedes hacer una prueba de unidad, pero no vale la pena" (estoy en un proyecto que ya está atrasado).

Pero el otro lado de mí dice, si no los pruebas de unidad y alguien cambia a los Guardias, entonces podría haber problemas.

Pero la primera parte de mí me responde: si alguien cambia a los guardias, entonces solo estás haciendo más trabajo para ellos (porque ahora tienen que cambiar los guardias y las pruebas unitarias para los guardias).

Por ejemplo, si mi servicio asume la responsabilidad de verificar la disponibilidad del Widget, es posible que ya no desee que el guardia lo haga. Si está en prueba de unidad, tengo que cambiar dos lugares ahora.

Veo pros y contras en ambos sentidos. Así que pensé en preguntar qué han hecho otros.

    
pregunta Vaccano 28.11.2012 - 18:05

5 respuestas

26
  

Una parte de mí dice "seguro que puedes hacer una prueba de unidad, pero no vale la pena" (estoy en un proyecto que ya está atrasado).

Son tres pruebas muy cortas. Pasaste todo el tiempo haciéndote la pregunta.

  

Pero el otro lado de mí dice, si no los pruebas de unidad y alguien cambia a los Guardias, entonces podría haber problemas.

Escucha este lado.

  

Pero la primera parte de mí me responde: si alguien cambia a los guardias, entonces solo estás haciendo más trabajo para ellos (porque ahora tienen que cambiar los guardias y las pruebas unitarias para los guardias).

Si su mantenedor es un fanático de TDD, se lo está haciendo más difícil. Cualquier cambio que realice sin que haya un cambio relacionado o la adición de pruebas me lleva a tener que pensar mucho. De hecho, probablemente agregaría las pruebas antes de seguir adelante y hacer el cambio.

La primera parte de ti es simplemente errónea. Dale a la segunda parte una palmadita en la espalda y deja de pensar en ello.

    
respondido por el pdr 28.11.2012 - 18:46
9

Simplificaría las pruebas unitarias si la lógica de guarda y el orden real fueran métodos separados.

En la clase Widget

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

o un método equivalente en otra parte

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

El método de pedido

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

Ahora la prueba IsWidgetReadyForOrdering se volvió fácil. No lo pienses mucho más. ¡Pruébalo!

    
respondido por el Olivier Jacot-Descombes 28.11.2012 - 18:15
6

Si no tiene tiempo en su programación para pruebas de unidad pero tiene tiempo para un uso de control de calidad sólido, pregunte si puede robar parte de ese tiempo de control de calidad para escribir pruebas de unidad, o si puede dedicar parte de el período de control de calidad que realiza las pruebas unitarias, o tal vez solo lidiar con el código no probado de la unidad ... Desafortunadamente, los programas que no se pueden mover lo obligan a hacer concesiones o a trabajar hasta la muerte, generalmente sugiero la primera opción porque la segunda resultará en que usted sea incapaz de soportar / mantener el sistema correctamente por el término del mismo.

Dicho esto, a tu pregunta general sobre las declaraciones de los guardias de prueba; ¡Sí! Absolutamente las declaraciones de guardia de prueba! Esas son partes importantes del comportamiento de ese método, no querría descubrir que alguien malinterpretó algo haciendo una corrección de errores y eliminó sus guardias o cambió el && a un || , ¿verdad? Las pruebas unitarias asegurarán que a) realmente hayas acertado la lógica de tus guardias yb) nadie rompa esa lógica más adelante sin recibir una queja cuando ejecute las pruebas unitarias, diciéndoles que debería ser así por alguna razón.

    
respondido por el Jimmy Hoffa 28.11.2012 - 18:46
0

Hay algunas respuestas excelentes arriba, y los puntos que hacen son muy importantes. Pero uno que parece haberse perdido es que si tiene un conjunto completo de pruebas de unidades, se leen como una especificación extremadamente detallada del código. Si omite la validación de prueba solo porque el código es tan fácil que es difícil ver cómo podría salir mal, falta parte de su especificación. Si entrara en un equipo en el que no se hubieran realizado estas pruebas, asumiría que su servicio no estaba validando sus argumentos.

    
respondido por el Jules 24.04.2017 - 19:31
-5

El código es el código. Debe intentar obtener una cobertura del 100% al realizar la prueba. Si no fuera importante, no estaría allí.

    
respondido por el SuperUser 24.04.2017 - 13:25

Lea otras preguntas en las etiquetas