Tests d'acceptation pour Tetris dans le cadre d'un développement piloté par les tests

Question

Je veux essayer d'implémenter le jeu Tetris en utilisant le TDD.

D'après ce que j'ai compris en lisant Développer des logiciels orientés objet, guidés par des tests Je devrais commencer par définir ce que seraient mes tests d'acceptation. Si j'ai bien compris, les tests d'acceptation sont définis de la même manière que les cas d'utilisation dans le cadre du TDD.

Il est très important de définir un bon premier test d'acceptation qui servira de "squelette" à l'application, il doit donc être assez simple.

J'ai choisi les deux tests d'acceptation suivants comme premiers à mettre en œuvre :

1. Le jeu commence et le joueur le clôt.
2. Le jeu commence et le joueur ne fait rien. Il finit par perdre.

Ces 2 tests d'acceptation sont-ils de bons tests de départ ? Quels seraient les prochains bons tests d'acceptation ? Je pourrais penser à quelque chose comme

• Le jeu commence et seules les pièces carrées tombent. Le joueur les place toutes de manière à ce que les lignes "explosent", ce qui fait que le jeu n'est toujours pas terminé après 100 pas de jeu.

mais j'ai l'impression que c'est un peu maladroit, car dans un vrai jeu de Tetris, il y aurait toujours des pièces différentes qui tomberaient, et c'est ce que les tests d'acceptation devraient faire.

De plus, je suis tenté d'essayer de tout mettre en œuvre en une seule fois lorsque je fais (2), ce qui, je pense, n'est pas le but recherché lorsque l'on met en œuvre le deuxième test d'acceptation. Je suppose que l'idée serait de n'implémenter le jeu qu'après 6-7 d'entre eux, et non pas lors du second. Ai-je raison ?

Remerciements

Answer 1

Je penserais d'abord au champ de jeu et à ce qu'il donne après un certain nombre d'images avec des blocs définis qui ont été lâchés. Par exemple, en utilisant Concombre :

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 vous aimez l'aspect des spécifications des fonctionnalités de Cucumber, vous pouvez essayer Cuke4Nuke pour .Net ou Cuke4Duke pour Java.

Answer 2

Vous voudrez retirer de vos tests les éléments aléatoires qui font partie de votre jeu. Certes, cela signifie que le test ne reproduit pas parfaitement le jeu, mais cela signifie aussi que vous avez des tests reproductibles, ce qui est d'une grande valeur. Isolez les différences - passez un PieceProvider dans votre jeu ; pour le jeu réel, passez un RandomPieceProvider, mais pour les tests, passez un SpecifiedPieceProvider. Il n'y a plus qu'une toute petite différence entre les deux, mais elle devrait être si minime qu'elle n'a pas d'importance ; vous pouvez toujours tester tous les autres aspects du jeu en toute confiance.

Answer 3

Commencez par une simple liste de blocs. En l'absence de joueur, les blocs s'empileront d'une certaine manière, puis se renverseront. Votre test échoue si les blocs ne s'empilent pas correctement ou si le programme ne détecte pas le débordement.