Primera prueba TDD sin excepción/espera esperada. ¿Vale la pena?

Question

Digamos que estoy empezando a hacer un juego con TDD. ¿Es esta una buena primera prueba?

[TestMethod] 
public void Can_Start_And_End_Game() 
{ 
    Tetris tetris = new Tetris(); 
    tetris.Start(); 
    tetris.End(); 
} 

Básicamente me obliga a definir 3 cosas: la clase Tetris y sus métodos Start() y End(), pero aparte de eso es bastante inútil. Puede tener su interés inmediatamente ya que con ellos puedo definir esa clase y esos métodos, pero más adelante probablemente no sirva para ningún tipo de propósito. Su único propósito podría mostrar que debe ser posible iniciar un juego y terminarlo sin obtener una excepción en el medio.

¿Qué piensas de eso?

Answer 1

Básicamente me obliga a definir 3 cosas: la clase Tetris y los métodos de su inicio() y End(),

verdadera.

pero además de eso es bastante inútil.

False.

más tarde, probablemente no servirá cualquier tipo de propósito

Falso, también.

Su propósito ... [es] que muestran que debe ser posible iniciar un juego y acabar con ella sin obtener una excepción en medio

Y eso es enorme. Épico. Monumental.

De hecho, esa prueba fallará tan a menudo que usted llegará a odiarla. Cada excepción no controlada y no controlada de todo tipo de lugares aleatorios en su programa no pasará esta prueba. Desarrollará un registro y depuración cuidadosos debido a esta prueba.

Esta prueba es EPIC.

Answer 2

creo que el propósito de la prueba puede ser más clara por la captura de las excepciones y explícitamente no supere la prueba si happpens:

[TestMethod] 
public void Can_Start_And_End_Game() 
{ 
    try 
    { 
     Tetris tetris = new Tetris(); 
     tetris.Start(); 
     tetris.End(); 
    } 
    catch (Exception ex) 
    { 
     Assert.Fail("Unexpected exception thrown: " + ex.ToString()); 
    } 
} 

Answer 3

No soy un gran fan de esta prueba. Sí, ayudó a definir la interfaz, pero no es muy fuerte para definir (y probar) el comportamiento.

Creo que podría ser mejor tener una prueba que maneje la puesta en marcha. Probablemente afirmaría la configuración predeterminada o los valores de puntuación. Luego, tendré pruebas adicionales para ver si puedes terminar un juego.

Lo ideal es que cada método de prueba ejecute un comportamiento.

Answer 4

Sí, la prueba confirma que no se lanza ninguna excepción en el constructor, el Start() y el método Stop().

Veo poco valor en un bloque de prueba/captura adicional dentro de la prueba para detectar excepciones. La herramienta que ejecuta la prueba los detectará e informará sobre ellos. Usando el principio TSTTCPW, la prueba puede funcionar sin el bloque try/catch.

Puede hacer que la prueba sea un poco más significativa agregando aserciones al final, por ejemplo validando el valor de las propiedades en el objeto tetris.

Tenga en cuenta la diferencia entre escribir una prueba de unidad y utilizar TDD. El valor viene de entender esa diferencia.

Answer 5

En realidad, no estás impulsando el desarrollo de la clase Tetris: has decidido cuál debería ser su API, lo cual está bien, pero ¿por qué no escribir una prueba que pruebe algo que realmente debería estar haciendo?

Las pruebas deben informar a la API, no al revés (imho).

Answer 6

Como dijo S. Lott, esta prueba cubre una TONELADA de terreno. Es por lo que "vale la pena" que vale la pena romper en al menos 3 pruebas y añadiendo afirmaciones correspondientes a cada uno:

[TestMethod] 
public void Test_Contructor() 
{ 
    Tetris tetris = new Tetris(); 
    // make assertions 
} 

[TestMethod] 
public void Test_Start() 
{ 
    // setup 
    Tetris tetris = new Tetris(); 

    // exercise 
    tetris.Start(); 

    // make assertions 
} 

[TestMethod] 
public void Test_End() 
{ 
    // setup 
    Tetris tetris = new Tetris(); 
    tetris.Start(); 

    // exercise 
    tetris.End(); 

    // make assertions 
}