¿TDD significa no pensar en el diseño de clase?

Question

Estoy haciendo un juego de rol para divertirme e intentar usar TDD mientras lo desarrollo. Muchos de los ejemplos de TDD que veo se enfocan primero en crear la prueba y luego en crear los objetos necesarios para que pase la prueba.

Por ejemplo:

[Test] 
public void Character_WhenHealthIsBelowZero_IsDead() 
{ 
    // create default character with 10 health 
    Character character = new Character(); 
    character.SubtractHealth(20); 
    Assert.That(character.IsAlive, Is.EqualTo(false)); 
} 

Así que basado en esto voy a crear la clase de caracteres y propiedades apropiadas/métodos. Esto parece estar bien y todo, ¿pero debería mi diseño de clase realmente salir de refinar continuamente mis pruebas? ¿Es mejor que trazar los posibles objetos que mi juego necesitará antes de tiempo? Por ejemplo, normalmente pensaría en una clase de personaje base, luego en subclases como Wizard, Fighter, Theif.

¿O es un enfoque equilibrado el camino a seguir? Una en la que planifico las posibles clases y la jerarquía que necesitaré, pero primero escribir pruebas para verificar que realmente se necesitan.

Answer 1

¿Debería salir realmente el diseño de mi clase de refinar continuamente mis pruebas?

Sí.

Does TDD significa no pensar en la clase design?

Absolutamente no. Significa pensar en el diseño de la clase mientras escribes tus pruebas y el resto de tu código. El diseño de la clase está en juego durante todo el ciclo de vida de Red-Green-Refactor TDD.

Answer 2

Creo que generalmente se supone (incluso por los puristas de TDD) que un programador que diseña una aplicación escribiendo pruebas ya sabe algo sobre diseño y arquitectura. De lo contrario, puede simplemente pintarse en el caos de programación y la anarquía escribiendo pruebas para el abandono de cualquier principio de diseño.

En consecuencia, un desarrollador que escribe una aplicación "prueba primero" ya tiene una idea clara de cómo será su estructura final de clase, y esa visión lo guía cuando está escribiendo sus pruebas.

Answer 3

TDD se trata de dejar que las pruebas impulsen su diseño, incluido el diseño de su clase. Esto es valioso porque las pruebas están destinadas a demostrar que el código "funciona". Eso significa que terminará con un diseño de clase de un programa que funciona, a diferencia de un diseño de clase de un programa que puede funcionar o no.

Answer 4

Creo que te estás perdiendo el punto de TDD. TDD no se trata de escribir pruebas: se trata de diseñar tus clases para que se puedan probar. Esto naturalmente conduce a un mejor diseño e implementación.

Parece que lo estás haciendo al revés.

Sus pasos deben ser:

1. del diseño de su modelo de dominio
2. Diseño de sus clases
3. escribir algunas pruebas
4. implementar algunas lógica de clase
5. Refactor sus clases para que sean más comprobable donde necesario
6. Repita los pasos 3-5

Answer 5

Creo que el enfoque equilibrado es el que debe tomar. Primero modele las clases de su dominio, porque sin ellas, ¿cómo sabe siquiera qué probar?

Luego, probablemente creará stubs o shells de estas clases, con implementaciones principalmente vacías, solo para permitirle escribir algunas estructuras de prueba.

Una vez hecho esto, es probable que sus casos de prueba iluminen la necesidad de nuevos métodos/clases/propiedades que no estaban en el diseño original, pero se descubren como necesarios.

Answer 6

Un enfoque equilibrado es el camino a seguir.

Sin embargo, la balanza es impulsada por la necesidad de probarla.

Puede mapear las posibles clases y la jerarquía. Sin embargo, tendrá que conducir el diseño (1) pensando en la capacidad de prueba y (2) escribiendo las pruebas antes de escribir demasiados códigos.

Para que sus pruebas incluso compilen, necesita algunas definiciones de clase. No tienen que trabajar, pero tienen que compilar.

En algunos casos, su clase puede ser tan simple que realmente escribe todos (o casi todos) primero.

Answer 7

TDD se trata de diseño! Entonces, al hacer TDD, estarás seguro de que tu diseño es completamente comprobable.

Además, el "enfoque equilibrado" es la manera de ir IMO. Usted ya sabe que una arquitectura de alto nivel y TDD impulsarán esta arquitectura para que sea comprobable.

EDITAR: Aunque, si solo quieres practicar TDD, no haría el "enfoque equilibrado". Simplemente haría TDD con "pasos de bebé" y tal vez codificando Dojos

Answer 8

TDD se inclina a pensar y experimentar con el diseño de clase concretamente usando el código de ejecución en lugar de hacerlo abstractamente con lápiz y papel.

Ambos enfoques son útiles. Incluso los fanáticos fanáticos de TDD usan lápiz y papel (o tal vez una pizarra) a veces, y los tipos de BDUF-ueber-alles harán saltar el prototipo ocasional. La pregunta entonces es dónde tiendes a caer: reflexivo o más práctico?