Mokona Guu Center

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

Le coût du TDD

Lorsque l'on s'intéresse au TDD (Test Driven Development), une question qui se pose est celle du temps supplémentaire qu'implique l'écriture des tests. C'est d'ailleurs l'une des principales craintes exprimées lorsque j'en explique les principes : « mais je vais perdre du temps ! »

Face à.ce temps supplémentaire à l'écriture, il est légitime …

Le tout premier test

Dans un programme que l'on voudrait écrire complètement conduits par les tests, quel est le premier test à écrire ?

Il est rare de commencer l'écriture d'un programme complet à partir de rien. Rare par rapport au temps passé à développer, modifier ou maintenir de l'existant. Il est un peu moins …

Test Driven Development : le gain facile

Le but des LucidPlayers de l'épisode précédent était de choisir un mouvement qui fait gagner immédiatement si possible. Autrement dit, de ne pas passer à côté d'une victoire évidente. C'est en ça qu'ils étaient lucides... en quelque sorte.

Je continue donc l'implémentation de cette stratégie en implémentant la recherche du …

Test Driven Development : parachutages lucides

La fois dernière, j'avais terminé à programmer des joueurs qui effectuaient des coups valides de mouvements et de capture. J'avais laissé de côté les parachutages ainsi que la détection d'une victoire immédiate.

Ce seront les sujets de cet épisode.

Parachutes

Afin de savoir s'il y a des pièces à parachuter …

Test Driven Development : des joueurs un peu moins fous

À présent que je peux lancer des parties avec des joueurs qui font des choix automatiquement, je vais implémenter des joueurs un peu moins automatiques que les précédents.

Leur but : ne pas passer à côté d'une victoire immédiate, c'est-à-dire lorsqu'il peut capturer le Lion adverse ou placer son Lion sur …

Test Driven Development : les joueurs fous

La fois dernière, j'avais déroulé une partie complète, scriptée, et vérifier l'état final. J'approche donc de la possibilité d'écrire les tests initiaux que je voulais effectuer au début de cette aventure : explorer les possibilités de parties de Dôbutsu Shôgi.

Le test fonctionnel du scénario n'est cependant pas terminé. En effet …

Test Driven Development : la suite de la partie

Au dernier épisode, j'avais commencé à implémenter un joueur afin de simuler le début d'une partie et vérifier que j'avais tous les outils pour une implémentation de partie complète jouée automatiquement.

Le code qui me permettait de bouger la giraffe était cependant redondant avec ce que j'avais déjà implémenté au …

Test Driven Development : le début d'une partie

À présent, sauf erreur, toutes les règles sont implémentées à l'exception de la détection d'une partie nulle. Il est temps de revenir à une session de jeu et de faire jouer deux joueurs automatiquement.

Pièce de Shôgi en bois

Les tests actuellement disponibles pour une session de jeu sont :

  • Session
    • Creates a board
    • Places the …

Test Driven Development : les pions valides

La fois dernière, j'avais extrait une interface de validation des mouvements. Il est maintenant temps d'implémenter les restrictions de mouvements des différentes pièces du Doubutsu Shogi. Et ceci, toujours selon la méthode TDD, en Python.

Pour le moment, j'ai extrait une interface grâce à un Mock Object.

Pièce de Shôgi en bois

    class MovementValidator:
        def …

Test Driven Development : le premier joueur

Rappel de l'épisode précédent là où je l'avais laissé. J'avais sélectionné deux nouvelles règles du jeu à implémenter. Le fait que le premier joueur était déterminé au hasard et le fait que chaque pièce était soumise à des déplacements contraints.

Piece de Shôgi en bois

Du hasard

Je commence donc pas la sélection du premier …

Page 1 / 3 >>>