¿Es útil para los métodos de prueba unitaria donde la única lógica son los guardias?

Digamos que tengo un método como este:

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

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

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

Una parte de mí dice "claro, puedes probarlos por unidad, pero no vale la pena" (estoy en un proyecto que ya está retrasado).

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

Pero la primera parte de mí dice que 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 quiera ese guardia. Si está bajo prueba unitaria, tengo que cambiar dos lugares ahora.

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

Una parte de mí dice "claro, puedes probarlos por unidad, pero no vale la pena" (estoy en un proyecto que ya está retrasado).

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

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

Escucha a este lado.

Pero la primera parte de mí dice que 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 loco de TDD, lo está haciendo más difícil para ellos. Cualquier cambio que realice sin que haya un cambio relacionado o la adición de pruebas me lleva a pensar mucho. De hecho, probablemente agregaría las pruebas antes de seguir adelante y hacer el cambio.

La primera parte de ti está simplemente equivocada. Dale una palmadita en la espalda a la segunda parte y deja de pensar en ello.

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

En la Widgetclase

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

o un método equivalente en otro lugar

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 las pruebas se IsWidgetReadyForOrderingvolvieron fáciles. No lo pienses mucho más. ¡Pruébalo!

Si no tiene tiempo en su cronograma para las pruebas unitarias, pero tiene tiempo reservado para un uso sólido del control de calidad, pregunte si puede robar algo de ese tiempo de control de calidad para escribir pruebas unitarias, o si puede pasar parte del período de control de calidad haciendo pruebas unitarias, o tal vez simplemente lidiando con un código no probado. Desafortunadamente, los horarios que son inamovibles lo obligan a hacer concesiones o trabajar hasta la muerte, generalmente sugiero la primera opción porque la segunda lo hará incapaz de apoyar / manteniendo el sistema correctamente por el término del mismo.

Dicho esto, a su pregunta general de probar las declaraciones de guardia; ¡Si! Absolutamente prueba declaraciones de guardia! Esas son partes importantes del comportamiento de ese método, no querrás descubrir que alguien malinterpretó algo haciendo una corrección de errores y eliminó a tus guardias o cambiaste &&a uno, ||¿verdad? Las pruebas unitarias asegurarán que a) usted realmente tenga la lógica correcta en sus guardias yb) nadie rompa esa lógica más tarde sin recibir una queja cuando ejecutan las pruebas unitarias diciéndoles que debería ser así por alguna razón.

Hay algunas respuestas excelentes anteriores, y los puntos que hacen son muy importantes. Pero uno que parece haberse perdido es que tiene un conjunto completo de pruebas unitarias, que 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 me uniera a un equipo donde estas pruebas se habían perdido, en realidad asumiría que su servicio no estaba validando sus argumentos.

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í.