¿La codificación y las pruebas unitarias violan el principio DRY?

El principio seco establece:

"Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema".

Sin embargo, al escribir pruebas para el código, está describiendo el comportamiento esperado para el sistema dos veces (una en el código y otra en la prueba). Sé que ambas descripciones son desde una perspectiva diferente, pero comparten una gran parte de la idea subyacente.

Tiene alguna idea sobre esto?

En general, creo que tanto las pruebas unitarias como el principio DRY son buenas ideas y trato de aplicarlas lo más posible. Esta pregunta es más a nivel filosófico, pero me preguntaba si alguien también había pensado en esto.

Estás operando en una premisa defectuosa.

El código no es una descripción del comportamiento esperado, solo lo son los requisitos y los casos de prueba. E incluso entonces, los requisitos y las pruebas definen dos lados del comportamiento. Los requisitos definen las características y la funcionalidad del sistema de software en su conjunto y la prueba define cuáles deberían ser los resultados esperados y se compara con los requisitos. El código es una interpretación del desarrollador de esos requisitos y la arquitectura del sistema.

No, no viola el principio DRY porque las pruebas unitarias no reproducen la funcionalidad, solo se aseguran de que la funcionalidad (re: responsabilidad) funcione correctamente. En el caso de una prueba unitaria, el método que está probando aún se mantiene authoritative representation. Su código de prueba puede ser muy similar al código que implementa el método en la versión de producción, pero tiene su propio propósito inequívoco (afirmar la prueba).

Mas o menos. Si son demasiado similares, entonces sí, eso es algo malo. Su prueba no debe codificarse de la misma manera que el código que está probando. Por lo tanto, debe definir (1) una expectativa y (2) una implementación.

Me gusta pensar que es similar a la contabilidad de doble entrada . Un sistema de contabilidad siempre realiza al menos 2 entradas (un débito y un crédito). Esta es una medida de comprobación de errores. Al final del día, los débitos y los créditos tienen que equilibrarse, o de lo contrario hubo un error. No puede tener un sistema de detección de errores sin alguna forma de redundancia.

Considere un CRC por ejemplo. Su byte CRC es una forma de redundancia. Es suficiente para detectar cualquier pequeño error en la señal. Del mismo modo, los CD de audio tienen mucha información redundante, por lo que aún se reproducen perfectamente si están rayados. ¿Eso viola el principio DRY? Probablemente, pero así es como obtienes confiabilidad.

También hay otra forma de verlo:

Su prueba es la respuesta autorizada. El código que prueba es generado automáticamente por usted, el código mono. Si pudiéramos generar automáticamente el código basado en pruebas unitarias (como si autogeneramos capas de acceso a datos basadas en un esquema de base de datos), no estaríamos violando el principio DRY (o al menos no el principio OAOO).

Sin embargo, al escribir pruebas para el código, está describiendo el comportamiento esperado para el sistema dos veces (una en el código y otra en la prueba).

No exactamente. El código no es la descripción del comportamiento esperado, sino su implementación . Que puede contener errores, por eso necesitamos las pruebas.

Implementar incluso un algoritmo o abstracción bastante simple es mucho más complicado que describirlo. Cualquier programador decente puede describir en pocas oraciones cómo funciona la búsqueda binaria; sin embargo, Jon Bentley informó que en sus experimentos, más del 70% de los programadores experimentados que participaron en su curso no pudieron implementarlo correctamente.

Es por eso que necesitamos pruebas unitarias. A nadie le gusta trabajar el doble para lograr los mismos resultados, pero todos aquellos desarrolladores que formularon y evangelizaron esta práctica se dieron cuenta de su propia experiencia duramente ganada que los necesitan. Eran personas inteligentes que querían desarrollar software lo más rápido posible, lo que requiere eliminar todas las tareas duplicadas e inútiles del proceso de desarrollo. Las pruebas unitarias no son un trabajo duplicado.