Mover el código existente a Test Driven Development

Question

Habiendo descubierto recientemente este método de desarrollo, me parece una metodología bastante buena. Entonces, para mi primer proyecto, tengo un pequeño código de DLL (en C # .NET, por lo que vale), y quiero hacer un conjunto de pruebas para este código, pero estoy un poco perdido en cuanto a cómo y por dónde empezar.

Estoy usando NUnit y VS 2008, cualquier sugerencia sobre qué clase de clases comenzar, para qué escribir las pruebas, y cualquier sugerencia sobre cómo ir sobre cómo mover el código a un desarrollo basado en pruebas será muy apreciada .

Answer 1

Vea el libro Trabajando efectivamente con código heredado por Michael Feathers.

En resumen, es mucho trabajo refactorizar el código existente en código comprobable y probado; A veces es demasiado trabajo para ser práctico. Depende de qué tan grande sea el código base, y de qué tanto dependen las distintas clases y funciones.

La refactorización sin pruebas introducirá cambios en el comportamiento (es decir, errores). Y los puristas dirán que no es realmente refactorización debido a la falta de pruebas para verificar que el comportamiento no cambie.

En lugar de agregar la prueba en general a toda la aplicación de una sola vez, agregue pruebas cuando trabaje en un área de código. Lo más probable es que tengas que volver a estos `` puntos de acceso '' otra vez.

Agregue pruebas de abajo hacia arriba: pruebe pequeñas y independientes funciones y funciones para ver si son correctas.

Agregue pruebas de arriba hacia abajo: pruebe subsistemas enteros como cajas negras para ver si su comportamiento cambia con los cambios en el código. Y así puedes pasar a través de ellos para averiguar qué está pasando. Este enfoque probablemente le proporcionará el mayor beneficio.

No se preocupe demasiado al principio con lo que el "correcto" el comportamiento es mientras agrega pruebas, busque detectar y evitar cambios en el comportamiento. Los sistemas grandes y no probados a menudo tienen comportamientos internos que pueden parecer incorrectos, pero de los que dependen otras partes del sistema.

Piense en aislar las dependencias, como la base de datos, el sistema de archivos, la red, para que puedan intercambiarse por proveedores de datos simulados durante las pruebas.

Si el programa no tiene interfaces internas, líneas que definen el límite entre un subsistema / capa y otra, entonces es posible que tenga que intentar introducirlas y probarlas.

Además, marcos de burla automáticos como Rhinomocks o Moq puede ayudar a simular las clases existentes aquí. Realmente no he encontrado la necesidad de ellos en el código diseñado para la capacidad de prueba.

Answer 2

Trabajar eficazmente con código heredado es mi biblia cuando se trata de migrar código sin pruebas en un entorno probado por unidad, y también proporciona mucha información sobre lo que hace que el código sea fácil de probar y cómo probarlo.

También encontré Test Driven Development by Example y Prueba de unidad pragmática: en C # con NUnit para ser una introducción decente a la prueba de unidad en ese entorno.

Un enfoque simple para iniciar TDD es comenzar a escribir pruebas primero a partir de este día y asegurarse de que cada vez que necesite tocar su código existente (sin prueba de unidad), escriba pruebas de aprobación que verifiquen el comportamiento existente del sistema antes de cambiarlo para que pueda volver a ejecutar esas pruebas para aumentar su confianza de que no ha roto nada.

Answer 3

Lo llamo " Test Driven Reverse Engineering " ;.

Comience " en la parte inferior " - Cada clase puede ser examinada por separado y una prueba escrita para ello. En caso de duda, adivina.

Cuando estás haciendo TDD ordinario en la dirección hacia adelante, tratas la prueba como sagrada y asumes que el código probablemente esté roto. A veces la prueba es incorrecta, pero su posición inicial es que es el código.

Cuando estás haciendo TDRE, el código es sagrado, hasta que puedas probar que el código tiene un error de larga data. En el caso inverso, escribe pruebas alrededor del código, ajusta las pruebas hasta que funcionen y afirma que el código funciona.

Entonces, puedes profundizar en el código malo. Algún mal cade tendrá casos de prueba sensibles, esto solo necesita ser limpiado. Algunos códigos erróneos, sin embargo, también tendrán un caso de prueba que no tiene sentido. Esto puede ser un error o un diseño torpe que puede corregir.

Para juzgar si el código está realmente equivocado, también debe comenzar en la parte superior con los casos de prueba generales. Los datos en vivo que realmente funcionan son un comienzo. Además, los datos en vivo que producen cualquiera de los errores conocidos, también son un buen lugar para comenzar.

He escrito pequeños generadores de código para convertir datos en vivo en casos de prueba de unidad. De esa manera, tengo una base consistente para pruebas y refactorización.

Answer 4

El código comprobable es fácil de detectar, según las pruebas que lo acompañan. Si hay algunos, debe ser comprobable. Si no hay ninguno - asume lo contrario. ;)

Dicho esto: Test Driven Development (TDD) no es tanto una estrategia de prueba como una estrategia de diseño. Las pruebas que usted escribe primero ayudan a diseñar la interfaz de sus clases, así como a obtener el alcance de sus clases (o subsistemas).

Tener las pruebas que creó durante TDD y ejecutarlas más tarde son buenas pruebas, pero es simplemente un efecto secundario (muy bienvenido) de esa filosofía de diseño.

Dicho esto, espere cierta resistencia de su código contra la prueba. Escuche su código y cambie la interfaz para que pueda comprobarse fácilmente. Lo más probable es que lo rediseñes cuando comiences a escribir pruebas.

Answer 5

Su DLL proporciona algún tipo de servicio. Para cada servicio, ¿qué debe hacer antes de obtener este servicio, qué parámetros debe pasar para obtener este servicio, cómo sabría que el servicio solicitado se ha ejecutado correctamente?

Una vez que tenga las respuestas a esas preguntas, puede escribir una primera prueba. Dichas pruebas preferirían llamarse pruebas de caracterización que pruebas de unidad, pero probablemente sería más fácil de escribir que las pruebas unitarias si la DLL no se desarrolló utilizando TDD.

Las pruebas de caracterización también se analizan en M. Feathers 'Working Effectively with Legacy Code', que se recomienda en otras respuestas.

También, asegúrese de escribir una prueba que falla antes de agregar cualquier nueva línea de código.