Mokona Guu Center

Mot-clé: python. Tous les mots-clés

Test Driven Development : les joueurs

C'est bien joli de déplacer des pièces sur un tableau de Shôgi. Mais dans le Shôgi, il y a deux joueurs qui s'affrontent, et pour le moment, mon programme ne gère pas du tout ce concept.

Et d'abord, par quel bord attaquer le problème ?

Puisqu'il y a deux joueurs qui …

Test Driven Development : les pièces se changent

J'ai beaucoup déplacé des pièces sur le tablier de Dôbutsu Shôgi jusqu'à maintenant. Pour le moment, il s'agit d'une implémentation où un joueur unique déplace des pièces un peu comme il le veut. Il peut aussi capturer des pièces et les parachuter.

J'aimerais à présent ajouter aux pièces les contraintes …

Test Driven Development : des pièces en double

Dans l'épisode précédent, j'avais extrait une classe Board pour faciliter l'implémentation de la possibilité d'avoir deux pièces identiques à des emplacements différents.

Tout d'abord, je vérifie que cela ne fonctionne bien pas.

    def test_can_have_two_identical_pieces_at_different_locations(self):
        first_location, second_location = ((0, 0), (0, 1))
        self.board.place_piece(PIECE_PAWN_P1, first_location)
        self.board.place_piece(PIECE_PAWN_P1 …

Test Driven Development : la prise du Lion !

Au tout début de mon voyage dans l'implémentation des règles du Dôbutsu Shôgi en utilisant le Test Driven Development, j'avais créé une fonction capture_lion, qui m'avait permis de démarrer.

Cette fonction était une fonction d'attente, et il est temps d'implémenter la condition de victoire de capture du lion correctement.

Pièce de Shôgi en bois

    def …

Test Driven Development : la réserve pour de vraie

À l'épisode précédent, j'avais utilisé un Mock Object pour révéler un début d'interface d'une classe Tray représentant la réserve dans laquelle vont les pions capturés au Dôbutsu Shôgi.

Dans cet épisode, je vais effectuer l'implémentation réelle de cette réserve.

Pièce de Shôgi en bois

Mais tout d'abord

À la fin de l'article précédent, je m'apercevais …

Test Driven Development : retour sur une erreur

Dans l'épisode « Mouvement et Capture » une erreur s'est glissée dans le programme. Je reviens un peu sur cette erreur, car elle donne une indication forte de ce qu'apporte le TDD et ce qu'il ne promet pas.

Un lecteur (lien cassé) m'a fait remarquer qu'il ne comprenait pas la ligne indiquée …

Test Driven Development : là où les pièces vont

Dans l'épisode précédent, le système permettait de capturer des pièces sur le tablier d'un Dôbutsu Shôgi. Cela se traduisait par la disparition d'une pièce lorsqu'une autre pièce effectuait un mouvement de capture explicite vers la position de la pièce capturée.

Aujourd'hui, je continue dans cette veine, car la capture au …

Test Driven Development : mouvement et capture

Puisque j'ai commencé à implémenter les tests de mouvements des pièces de Dôbutsu Shogi, je vais continuer dans cette veine pour cette session.

Pour le moment, nous pouvons déplacer une pièce d'un ou deux mouvements. Cependant, aucune gestion de validité n'est gérée. Que se passe-t-il si deux pions sont installés …

Test Driven Development : du mouvement

Je continue ma construction de programme implémentant les règles du Dôbutsu Shôgi en utilisant le Test Driven Development.

Cet article fait parti d'un ensemble dont voici les épisodes précédents :

Pièce de Shôgi en bois

Dans l'épisode précédent, j'avais créé une classe ShogiGame par extraction des méthodes de la classe …

Test Driven Development : parachutes

Bienvenue dans le troisième article dans lequel je continue la progression dans l'étude des parties de Dôbutsu Shôgi possibles en utilisant le TDD.

Dans l'article précédent, j'étais arrivé à un état où une partie était commencée, un lion capturé, et je vérifiais alors qu'il y avait un gagnant.

Le dernier …

<<< Page 2 / 3 >>>