Estoy tratando de entender TDD, específicamente la parte de desarrollo. He visto algunos libros, pero los que encontré abordan principalmente la parte de prueba: la Historia de NUnit, por qué la prueba es buena, Rojo / Verde / Refactor y cómo crear una Calculadora de cadenas.
Cosas buenas, pero eso es "solo" Prueba de Unidad, no TDD. Específicamente, no entiendo cómo TDD me ayuda a obtener un buen diseño si necesito un diseño para comenzar a probarlo.
Para ilustrar, imagine estos 3 requisitos:
- Un catálogo necesita tener una lista de productos.
- El catálogo debe recordar qué productos ha visto un usuario
- Los usuarios deberían poder buscar un producto
En este punto, muchos libros sacan un conejo mágico de un sombrero y simplemente se sumergen en "Probar el Servicio del Producto", pero no explican cómo llegaron a la conclusión de que hay un Servicio del Producto en primer lugar. Esa es la parte "Desarrollo" en TDD que estoy tratando de entender.
Es necesario que exista un diseño existente, pero no se encuentran elementos fuera de los servicios de la entidad (es decir: hay un producto, por lo que debe haber un servicio de producto) (por ejemplo, el segundo requisito requiere que tenga algún concepto de un Usuario, pero ¿dónde pondría la funcionalidad para recordar? ¿Y la búsqueda es una característica del ProductService o un SearchService separado? ¿Cómo sabría cuál debo elegir?)
Según SOLID , necesitaría un servicio de usuario, pero si diseño un sistema sin TDD, podría terminar con un montón de servicios de método único. ¿TDD no tiene la intención de hacerme descubrir mi diseño en primer lugar?
Soy desarrollador de .net, pero los recursos de Java también funcionarían. Siento que no parece haber una aplicación o libro de muestra real que trate con una línea real de aplicación comercial. ¿Alguien puede proporcionar un ejemplo claro que ilustre el proceso de creación de un diseño usando TDD?