Tengo bastante conocimiento de las pruebas unitarias. He estado tratando de leer sobre contratos de código. ¿Realmente ayuda a las pruebas unitarias? ¿Está sobrevalorado, especialmente cuando hablamos de contrato por código, ayudando a hacer pruebas unitarias? Me refiero específicamente a los contratos en .net 4.0. Yo uso nunit para pruebas unitarias.¿Los contratos de código realmente ayudan a las pruebas unitarias?
Sí y No. Las pruebas unitarias son básicamente un contrato que dice: MyMethod() toma X y espera que Y sea un resultado, y cuando no lo hace, las pruebas unitarias fallan y usted es alertado como el desarrollador de MyMethod() que se rompió algo dentro de eso. Los contratos de código lo ayudan a escribir pruebas unitarias, porque los requisitos en los contratos le facilitan saber los requisitos de las pruebas unitarias cuando los escribe. Sin embargo, la verdadera razón para los contratos de código no es para ti, sino para otros desarrolladores que usan la API que creas. Las pruebas unitarias le permiten conocer las entradas y salidas correctas, pero cuando libera el código en la naturaleza, las pruebas unitarias no se lanzan con el .dll. Los contratos de código otorgan a otros desarrolladores de la ventaja de saber, mediante contratos y verificación en tiempo de compilación, esos mismos requisitos. Los contratos protegen contra los desarrolladores (yo) que tienen una horrible tendencia a no leer la documentación del método y simplemente comienzan a pasar cosas, por lo que ahora serán advertidos activamente a través de contratos.
No, no creo que los contratos de código lo ayuden a escribir pruebas unitarias. Las pruebas unitarias definen el comportamiento y las restricciones de una acción determinada. Una de esas especificaciones escritas en las pruebas unitarias podría ser que los argumentos a un método no pueden ser nulos.
En ese caso, aún necesita escribir la prueba de la unidad. El contrato de código es una forma de implementar su especificación, pero no la única.
En otras palabras, no asuma que usar un contrato de código significa que no tiene que escribir una prueba de unidad! Si alguien cambia el contrato del código o lo elimina, no tendrá una prueba que le diga que esa especificación prevista ha fallado.
No creo que nadie dijera que los contratos de código deberían reemplazar las pruebas unitarias. –
Acepto que los contratos no ayudan a escribir pruebas unitarias. Idealmente, las pruebas deberían ser lo primero, por lo que no deberían existir contratos hasta que no haya una prueba que falla. Los contratos pueden escribirse para hacer cumplir las pruebas negativas ("debería arrojar"). –
Los contratos de código se pueden usar para cosas que no se pueden usar pruebas unitarias (contratos para interfaces). Se aplican en cadenas de herencia (donde puede cometer errores fácilmente con las pruebas de unidades manuales). Proporcionan documentación automáticamente (algo que las pruebas unitarias no pueden hacer). Pueden proporcionar comprobaciones en tiempo de ejecución en producción (algo que las pruebas unitarias no pueden hacer).
Por otro lado, los contratos solo fallan cuando se ejecutan, por lo que sin pruebas unitarias no se garantiza la calidad del código (es decir, que todos los códigos cumplen los diversos contratos). Los dos conceptos son complementarios.
¿Pero eso no duplicará mi lógica? Quiero decir, tendremos la misma lógica (condiciones previas y posteriores) para contratos y pruebas unitarias. –
Lo hará, y desde un punto de vista purista, debería hacerlo, ya que si alguien elimina accidentalmente el contrato, las pruebas unitarias seguirían verificando la lógica de que no desea que haga algo que ahora puede hacer, o viceversa. Los contratos pueden ser una guía para escribir pruebas unitarias, pero aún no son un reemplazo para ellos. –
Me resulta difícil aceptar que los contratos dupliquen las pruebas unitarias. Los contratos de código establecen los requisitos, las pruebas unitarias verifican que son ciertos. En cierto sentido, las pruebas verifican que sus contactos son correctos: los contratos son códigos entregables y, por lo tanto, deben probarse. –