Pruebas de aceptación para Tetris cuando se usa Desarrollo controlado por prueba

Question

Quiero intentar implementar el Juego Tetris usando TDD.

Por lo que he entendido al leer Growing Object-Oriented Software, Guided by Tests, debería comenzar por definir cuáles serían mis pruebas de aceptación. Si estoy en lo cierto, las pruebas de aceptación cuando se hace TDD se definen como casos de uso.

Es de gran importancia definir una buena primera prueba de aceptación que funcione como "esqueleto" de la aplicación, por lo que debería ser algo simple.

que he elegido los siguientes 2 Pruebas de Aceptación como mi primer implementar:

1. se inicia el juego y el jugador lo cierra.
2. Comienza el juego y el jugador no hace nada. Él eventualmente pierde.

¿Son estas 2 pruebas de aceptación buenas pruebas de inicio? ¿Cuáles serían las próximas pruebas de aceptación? Podría pensar en algo así como

• El juego comienza y solo caen las piezas cuadradas. El jugador los coloca a todos de manera tal que las líneas siempre "explotan", haciendo que el Juego después de 100 pasos del juego aún no haya terminado.

pero siento que esto es un poco incómodo, ya que en un juego real de Tetris siempre tendrías diferentes piezas cayendo, y de eso se trata la Prueba de Aceptación.

Además, me siento un poco tentado de solo intentar implementar todo de una sola vez al hacer (2), que creo que no es el mismo cuando se implementa la segunda Prueba de aceptación. Supongo que la idea sería implementar el juego solo después de como 6-7 de ellos, no en el segundo. ¿Estoy en lo cierto?

Gracias

Answer 1

Pensaré primero en el campo de juego y en cómo se ve después de que se hayan eliminado varios cuadros con algunos bloques definidos. Por ejemplo, usando Cucumber:

Scenario: dropping the first square 
    Given an empty 10x2 field 

    When a square is dropped at column 4 
    And 48 frames have passed 

    Then the field should contain a square at (4, 1) 

    When 48 frames have passed 
    Then the field should contain a square at (4, 2) 

Scenario: Dropping a square on a full stack 
    Given an empty 10x2 field 
    And a square at (4, 2) 

    When a square is dropped at column 4 
    And 48 frames have passed 

    Then the game should be over 

Si te gusta el aspecto de pepino característica especificaciones, es posible que desee probar Cuke4Nuke para .Net o Cuke4Duke para Java.

Answer 2

Comience con una simple lista de bloques. Asumiendo que no hay jugador, los bloques se acumularán de cierta manera y luego se derramarán. Su prueba falla si los bloques no se acumulan correctamente o si el programa no detecta el derrame.

Answer 3

Querrá eliminar de sus pruebas la aleatoriedad que pertenece a su juego. Sí, esto significa que la prueba no duplica perfectamente el juego, pero también significa que tiene pruebas repetibles, y eso es de mayor valor. Aísle las diferencias: pase un PieceProvider a su juego; para el juego real pasa un RandomPieceProvider, pero para las pruebas pasa en un SpecifiedPieceProvider. Ahora solo tienes una pequeña diferencia entre ellos, pero la diferencia debería ser tan pequeña como para no importar; aún puedes probar todos los demás aspectos del juego con confianza.