¿TDD hace redundante la programación defensiva?

Las pruebas están ahí para apoyar y garantizar la programación defensiva

La programación defensiva protege la integridad del sistema en tiempo de ejecución.

Las pruebas son herramientas de diagnóstico (en su mayoría estáticas). En el tiempo de ejecución, sus pruebas no están a la vista. Son como los andamios que se usan para levantar un alto muro de ladrillos o una cúpula de roca. No deja partes importantes fuera de la estructura porque tiene un andamio que la sostiene durante la construcción. Usted tiene un andamio que lo sostiene durante la construcción para facilitar colocar todas las piezas importantes.

EDITAR: una analogía

¿Qué pasa con una analogía a los comentarios en código?

Los comentarios tienen su propósito, pero pueden ser redundantes o incluso dañinos. Por ejemplo, si pone conocimiento intrínseco sobre el código en comentarios , luego cambia el código, los comentarios se vuelven irrelevantes en el mejor de los casos y dañinos en el peor.

Entonces, digamos que usted pone mucho conocimiento intrínseco de su base de código en las pruebas, como que MethodA no puede tomar un nulo y el argumento de MethodB debe ser > 0 . Entonces el código cambia. Nulo está bien para A ahora, y B puede tomar valores tan pequeños como -10. Las pruebas existentes ahora son funcionalmente incorrectas, pero continuarán pasando.

Sí, debería actualizar las pruebas al mismo tiempo que actualiza el código. También debe actualizar (o eliminar) los comentarios al mismo tiempo que actualiza el código. Pero todos sabemos que estas cosas no siempre suceden, y que se cometen errores.

Las pruebas verifican el comportamiento del sistema. Ese comportamiento real es intrínseco al sistema en sí mismo, no intrínseco a las pruebas.

¿Qué podría salir mal?

El objetivo con respecto a las pruebas es idear todo lo que podría salir mal, escribir una prueba que verifique el comportamiento correcto, luego diseñar el código de tiempo de ejecución para que pase todas las pruebas.

Lo que significa que la programación defensiva es el punto .

TDD acciona la programación defensiva, si las pruebas son exhaustivas.

Más pruebas, conduciendo más programación defensiva

Cuando los errores se encuentran inevitablemente, se escriben más pruebas para modelar las condiciones que manifiestan el error. Luego el código se corrige, con el código para hacer que se pasen las pruebas de esas , y las nuevas pruebas permanezcan en la suite de pruebas.

Un buen conjunto de pruebas pasará argumentos buenos y malos a una función / método y esperará resultados consistentes. Esto, a su vez, significa que el componente probado utilizará controles de condición previa (programación defensiva) para confirmar los argumentos que se le pasaron.

Hablando genéricamente ...

Por ejemplo, si un argumento nulo para un procedimiento en particular no es válido, entonces al menos una prueba pasará un nulo y esperará una excepción / error de "argumento nulo no válido" de algún tipo.

Por lo menos otra prueba pasará un argumento válido , por supuesto, o pasará a través de una gran matriz y pasará innumerables argumentos válidos, y confirmará que el estado resultante es adecuado.

Si un test no pasa ese argumento nulo y recibe una bofetada con la excepción esperada (y esa excepción fue lanzada porque el código verificó el estado pasado a la defensiva), entonces el nulo puede terminar asignados a una propiedad de una clase o enterrados en una colección de algún tipo donde no debería estar.

Esto podría causar un comportamiento inesperado en una parte completamente diferente del sistema a la que se pasa la instancia de la clase, en algún lugar geográfico distante después de que el software se haya enviado . Y ese es el tipo de cosas que estamos tratando de evitar, ¿no?

Incluso podría ser peor. La instancia de clase con el estado no válido podría ser serializada y almacenada, solo para causar una falla cuando se reconstituye para su uso posterior. Caray, no sé, quizás sea un sistema de control mecánico de algún tipo que no se puede reiniciar después de un apagado porque no puede deserializar su propio estado de configuración persistente. O la instancia de la clase se podría serializar y pasar a un sistema completamente diferente creado por alguna otra entidad, y ese sistema podría fallar.

Especialmente si los programadores de ese otro sistema no codificaron a la defensiva.

En lugar de TDD, hablemos de "pruebas de software" en general, y en lugar de "programación defensiva" en general, hablemos de mi forma favorita de hacer programación defensiva, que es mediante el uso de aserciones.

Entonces, ya que hacemos pruebas de software, deberíamos dejar de colocar declaraciones de afirmación en el código de producción, ¿verdad? Déjame contar las formas en que esto está mal:

1. Las aserciones son opcionales, por lo tanto, si no te gustan, simplemente ejecuta tu sistema con las aserciones deshabilitadas.

2. Las aserciones comprueban lo que las pruebas no pueden (y no deberían). Se supone que las pruebas tienen una vista de caja negra de su sistema, mientras que las aserciones tienen una vista de caja blanca. (Por supuesto, ya que viven en él).

3. Las afirmaciones son una excelente herramienta de documentación. Ningún comentario fue, ni nunca será, tan inequívoco como una pieza de código que afirma lo mismo. Además, la documentación tiende a quedar desactualizada a medida que el código evoluciona, y no es de ninguna manera exigible para el compilador.

4. Las aserciones pueden detectar errores en el código de prueba. ¿Alguna vez se ha encontrado con una situación en la que falla una prueba y no sabe quién está equivocado: el código de producción o la prueba?

5. Las afirmaciones pueden ser más pertinentes que las pruebas. Las pruebas verifican lo que prescriben los requisitos funcionales, pero el código a menudo tiene que hacer ciertas suposiciones que son mucho más técnicas que eso. Las personas que escriben documentos de requisitos funcionales rara vez piensan en la división por cero.

6. Las aserciones señalan errores que las pruebas solo apuntan en términos generales. Por lo tanto, su prueba establece algunas condiciones previas extensas, invoca un trozo de código largo, recopila los resultados y encuentra que no son como se esperaba. Teniendo en cuenta la suficiente solución de problemas, eventualmente encontrará exactamente dónde las cosas salieron mal, pero las aseveraciones generalmente lo encontrarán primero.

7. Las aserciones reducen la complejidad del programa. Cada línea de código que escriba aumenta la complejidad del programa. Las aserciones y la palabra clave final ( readonly ) son las únicas dos construcciones que conozco que realmente reducen la complejidad del programa. Eso no tiene precio.

8. Las aserciones ayudan al compilador a entender mejor su código. Por favor, intente esto en casa: void foo( Object x ) { assert x != null; if( x == null ) { } } su compilador debería emitir una advertencia que le dice que la condición x == null siempre es falsa. Eso puede ser muy útil.

Lo anterior fue un resumen de una publicación de mi blog, 2014-09-21 "Assertions y pruebas "

Creo que a la mayoría de las respuestas les falta una distinción crítica: depende de cómo se vaya a utilizar su código.

¿El módulo en cuestión será utilizado por otros clientes independientemente de la aplicación que está probando? Si proporciona una biblioteca o API para uso de terceros, no tiene forma de asegurarse de que solo llamen a su código con una entrada válida. Tienes que validar todas las entradas.

Pero si el módulo en cuestión solo lo usa el código que controlas, entonces tu amigo puede tener un punto. Puede usar pruebas unitarias para verificar que el módulo en cuestión solo se llame con una entrada válida. Las verificaciones de condición previa aún se pueden considerar una buena práctica, pero es una compensación: usted desecha el código que verifica la condición que sabe nunca puede surgir, simplemente oculta la intención del código.

No estoy de acuerdo con que las verificaciones de precondición requieran más pruebas unitarias. Si decide que no necesita probar algunas formas de entrada no válida, entonces no debería importar si la función contiene comprobaciones de condición previa o no. Recuerde que las pruebas deben verificar el comportamiento, no los detalles de la implementación.

Este tipo de argumento me desconcierta, porque cuando comencé a practicar TDD, mi unidad comprueba la forma "el objeto responde < de cierta manera > cuando < entrada no válida >" Incremento 2 o 3 veces. Me pregunto cómo se las arregla su colega para pasar con éxito esos tipos de pruebas unitarias sin que sus funciones hagan la validación.

El caso inverso, que las pruebas de unidad muestran que nunca está produciendo salidas malas que pasarán a los argumentos de otras funciones, es mucho más difícil de probar. Al igual que en el primer caso, depende en gran medida de la cobertura completa de los casos perimetrales, pero tiene el requisito adicional de que todas las entradas de sus funciones deben provenir de las salidas de otras funciones cuyas salidas ha probado la unidad y no de, por ejemplo, la entrada del usuario o Módulos de terceros.

En otras palabras, lo que hace TDD no impide que necesite el código de validación, sino que lo ayuda a evitar que lo olvide .

Creo que interpreto las observaciones de su colega de manera diferente a la mayoría de las demás respuestas.

Me parece que el argumento es:

• Todo nuestro código está probado en la unidad.
• Todo el código que usa su componente es nuestro código, o si no lo hace, otra persona lo prueba (no se establece explícitamente, pero es lo que entiendo de "las pruebas unitarias deben detectar cualquier uso incorrecto de la clase").
• Por lo tanto, para cada persona que llama a su función, hay una prueba de unidad en algún lugar que simula su componente, y la prueba falla si la persona que llama pasa un valor no válido a esa simulación.
• Por lo tanto, no importa lo que haga su función cuando se pasa un valor no válido, porque nuestras pruebas dicen que no puede suceder.

Para mí, este argumento tiene cierta lógica, pero confía demasiado en las pruebas unitarias para cubrir todas las situaciones posibles. El hecho simple es que el 100% de cobertura de línea / rama / ruta no ejerce necesariamente cada valor que la persona que llama puede pasar, mientras que el 100% de cobertura de todos los estados posibles de la persona que llama (es decir, , todos los valores posibles de sus entradas y variables) no son computables.

Por lo tanto, tiendo a preferir realizar pruebas unitarias de las personas que llaman para garantizar que (en lo que respecta a las pruebas) nunca pasen valores incorrectos, y adicionalmente para exigir que su componente falle en algunos forma reconocible cuando se pasa un valor incorrecto (al menos en la medida en que es posible reconocer valores incorrectos en el idioma que elija). Esto ayudará a la depuración cuando ocurran problemas en las pruebas de integración, y también ayudará a cualquier usuario de su clase que sea menos riguroso en aislar su unidad de código de esa dependencia.

Tenga en cuenta, sin embargo, que si documenta y prueba el comportamiento de su función cuando se pasa un valor < = 0, entonces los valores negativos ya no serán válidos (al menos, no más inválido que cualquier argumento en absoluto para throw , ya que eso también está documentado para lanzar una excepción!). Las personas que llaman tienen derecho a confiar en ese comportamiento defensivo. Si el idioma lo permite, puede ser que en cualquier caso este sea el mejor escenario: la función no tiene "entradas inválidas", pero las personas que llaman que esperan no provocar la función para lanzar una excepción deben ser la unidad- probado lo suficiente para garantizar que no pasen ningún valor que cause eso.

A pesar de pensar que su colega está algo menos equivocado que la mayoría de las respuestas, llego a la misma conclusión, que es que las dos técnicas se complementan entre sí. Programe a la defensiva, documente sus controles defensivos y pruébelos. El trabajo solo es "innecesario" si los usuarios de su código no pueden beneficiarse de mensajes de error útiles cuando cometen errores. En teoría, si prueban a fondo todo su código antes de integrarlo con el suyo, y nunca hay errores en sus pruebas, nunca verán los mensajes de error. En la práctica, incluso si están realizando TDD y la inyección de dependencia total, aún podrían explorar durante el desarrollo o podría haber un lapso en sus pruebas. ¡El resultado es que llaman a tu código antes de que su código sea perfecto!

Las interfaces públicas pueden y serán mal utilizadas

La reclamación de su compañero de trabajo "las pruebas unitarias deben detectar cualquier uso incorrecto de la clase" es estrictamente falsa para cualquier interfaz que no sea privada. Si se puede llamar a una función pública con argumentos enteros, entonces se puede y se llamará con cualquier argumentos enteros, y el código debe comportarse de manera apropiada. Si una firma de función pública acepta, por ejemplo, Java doble, luego nulo, NaN, MAX_VALUE, -Inf son todos valores posibles. Sus pruebas unitarias no pueden detectar usos incorrectos de la clase porque esas pruebas no pueden probar el código que usará esta clase, ya que el código aún no está escrito, es posible que no lo haya hecho usted y que definitivamente esté fuera del alcance de tus pruebas unitarias

Por otra parte, este enfoque puede ser válido para las propiedades privadas (con suerte mucho más numerosas), si una clase puede garantizar que algún hecho siempre es cierto (por ejemplo, la propiedad X nunca puede ser nula , la posición del entero no excede la longitud máxima, cuando se llama a la función A, todas las estructuras de datos de requisitos previos están bien formadas), entonces puede ser apropiado evitar verificar esto una y otra vez por razones de rendimiento, y confiar en las pruebas unitarias en su lugar.

La defensa contra el uso indebido es una característica , desarrollada debido a un requisito para ello. (No todas las interfaces requieren controles rigurosos contra el uso indebido; por ejemplo, los internos son muy limitados).

La función requiere pruebas: ¿realmente funciona la defensa contra el uso indebido? El objetivo de probar esta función es tratar de demostrar que no es así: crear un mal uso del módulo que no se ha detectado en sus comprobaciones.

Si las verificaciones específicas son una característica requerida, de hecho no tiene sentido afirmar que la existencia de algunas pruebas las hace innecesarias. Si es una característica de alguna función que (digamos) lanza una excepción cuando el parámetro tres es negativo, entonces eso no es negociable; hará eso.

Sin embargo, sospecho que su colega realmente tiene sentido desde el punto de vista de una situación en la que no hay un requisito para controles específicos en las entradas, con respuestas específicas a entradas incorrectas: una situación en el que solo hay un requisito general comprendido de robustez.

Las verificaciones al ingresar a alguna función de nivel superior están ahí, en parte, para proteger a algunos códigos internos débiles o mal probados de combinaciones inesperadas de parámetros (por ejemplo, si el código está bien probado, los chequeos no son necesarios: el código puede simplemente "capear" los parámetros incorrectos).

Hay una verdad en la idea del colega, y lo que él probablemente quiere decir es esto: si construimos una función a partir de piezas muy robustas de nivel inferior que están codificadas a la defensiva y probadas individualmente contra todo mal uso, entonces es posible para el nivel más alto La función es robusta sin tener sus propias autocomprobaciones extensas.

Si se viola su contrato, entonces se traducirá en un uso incorrecto de las funciones de nivel inferior, tal vez lanzando excepciones o lo que sea.

El único problema con eso es que las excepciones de nivel inferior no son específicas de la interfaz de nivel superior. Si eso es un problema depende de cuáles son los requisitos. Si el requisito es simplemente "la función será robusta contra el uso indebido y lanzará algún tipo de excepción en lugar de fallar, o continuará calculando con datos de basura", de hecho podría estar cubierta por toda la robustez de las piezas de nivel inferior en las que se encuentra. construido.

Si la función tiene un requisito para informes de errores muy específicos y detallados relacionados con sus parámetros, las verificaciones de nivel inferior no satisfacen esos requisitos por completo. Solo se aseguran de que la función explote de alguna manera (no continúa con una mala combinación de parámetros, lo que produce un resultado de basura). Si el código del cliente se escribe para detectar específicamente ciertos errores y manejarlos, es posible que no funcione correctamente. El propio código de cliente podría estar obteniendo, como entrada, los datos en los que se basan los parámetros, y podría estar esperando que la función los compruebe y que traduzca los valores erróneos a los errores específicos documentados (para que pueda manejarlos). errores correctamente) en lugar de otros errores que no se manejan y tal vez detengan la imagen del software.

TL; DR: tu colega probablemente no es un idiota; simplemente están hablando uno al lado del otro con diferentes perspectivas en torno a lo mismo, porque los requisitos no están totalmente definidos y cada uno de ustedes tiene una idea diferente de lo que son los "requisitos no escritos". Piensa que cuando no hay requisitos específicos en la verificación de parámetros, debe codificar la verificación detallada de todos modos; el colega piensa, simplemente deje que el robusto código de nivel inferior explote cuando los parámetros estén equivocados. Es un tanto improductivo discutir sobre requisitos no escritos a través del código: reconozca que no está de acuerdo sobre los requisitos en lugar del código. Su forma de codificación refleja lo que cree que son los requisitos; El camino del colega representa su visión de los requisitos. Si lo ves de esa manera, está claro que lo que está bien o mal no está en el código en sí; El código es solo un proxy para su opinión de lo que debería ser la especificación.

Las pruebas definen el contrato de tu clase.

Como corolario, la ausencia de una prueba define un contrato que incluye comportamiento no definido . Por lo tanto, cuando pasa null a Foo::Frobnicate(Widget widget) , y se producen innumerables estragos en el tiempo de ejecución, todavía está dentro del contrato de su clase.

Más tarde, usted decide: "no queremos la posibilidad de un comportamiento indefinido", que es una opción sensata. Eso significa que tienes que tener un comportamiento esperado para pasar null a Foo::Frobnicate(Widget widget) .

Y usted documenta esa decisión al incluir un

[Test]
void Foo_FrobnicatesANullWidget_ThrowsInvalidArgument() 
{
    Given(Foo foo);
    When(foo.Frobnicate(null));
    Then(Expect_Exception(InvalidArgument));
}

Un buen conjunto de pruebas ejercerá la interfaz externa de su clase y garantizará que dichos usos incorrectos generen la respuesta correcta (una excepción, o lo que sea que defina como "correcto"). De hecho, el primer caso de prueba que escribo para una clase es llamar a su constructor con argumentos fuera de rango.

El tipo de programación defensiva que tiende a eliminarse con un enfoque totalmente probado por unidades es la validación innecesaria de invariantes internos que no pueden ser violados por un código externo.

Una idea útil que a veces utilizo es proporcionar un método que pruebe las invariantes del objeto; su método de desmontaje puede llamarlo para validar que sus acciones externas en el objeto nunca rompen las invariantes.

Las pruebas de TDD detectarán errores durante el desarrollo del código .

La verificación de límites que describe como parte de la programación defensiva detectará errores durante el uso del código .

Si los dos dominios son iguales, es decir, el código que está escribiendo solo se usa internamente en este proyecto específico, entonces puede ser cierto que TDD excluirá la necesidad de los límites de programación defensivos que usted describe, pero solo si esos tipos de verificación de límites se realizan específicamente en las pruebas TDD .

Como ejemplo específico, suponga que se desarrolló una biblioteca de código financiero utilizando TDD. Una de las pruebas podría afirmar que un valor particular nunca puede ser negativo. Eso garantiza que los desarrolladores de la biblioteca no hagan un mal uso accidental de las clases al implementar las características.

Pero después de que se publica la biblioteca y la estoy usando en mi propio programa, esas pruebas TDD no me impiden asignar un valor negativo (suponiendo que esté expuesto). La verificación de límites lo haría.

Mi punto es que, si bien una afirmación de TDD podría abordar el problema del valor negativo si el código solo se usa internamente como parte del desarrollo de una aplicación más grande (bajo TDD), si va a ser una biblioteca utilizada por otros programadores sin el marco y las pruebas de TDD , la verificación de límites es importante.

TDD y la programación defensiva van de la mano. Usar ambos no es redundante, sino complementario. Cuando tiene una función, desea asegurarse de que la función funciona como se describe y escribir pruebas para ella; Si no cubre lo que sucede cuando en el caso de una entrada incorrecta, un rendimiento incorrecto, un estado incorrecto, etc., no está escribiendo sus pruebas con la suficiente firmeza y su código será frágil incluso si todas sus pruebas están pasando.

Como ingeniero integrado, me gusta usar el ejemplo de escribir una función para simplemente agregar dos bytes y devolver el resultado de esta manera:

uint8_t AddTwoBytes(uint8_t a, uint8_t b, uint8_t *sum); 

Ahora, si simplemente hicieras *(sum) = a + b , funcionaría, pero solo con algunas entradas. a = 1 y b = 2 harían sum = 3 ; sin embargo, debido a que el tamaño de la suma es un byte, a = 100 y b = 200 harían sum = 44 debido al desbordamiento. En C, devolvería un error en este caso para indicar que la función falló; lanzar una excepción es lo mismo en su código. No considerar las fallas o probar cómo manejarlas no funcionará a largo plazo, ya que si se producen esas condiciones, no se manejarán y podrían causar muchos problemas.