Un groupe propose ce prototype

Deux raisons.

• Elle fait trois choses. Tester « applique le coup » oblige à subir l'affichage, et tester « dit si la partie est finie » oblige à appliquer un coup. On ne peut vérifier aucune des trois séparément, alors que chacune est simple isolément.
• Elle mêle un calcul et une sortie à l'écran. Un test peut comparer une valeur renvoyée ; il ne peut pas comparer ce qui a été imprimé sans détourner print. Le paramètre affiche=True l'avoue à demi-mot : on a senti la gêne, et on a ajouté un interrupteur au lieu de séparer.

La découpe.

def coup_legal(g, i, j):
    """Le coup (i, j) est-il jouable sur g ? Ne modifie rien."""

def appliquer(g, i, j, joueur):
    """Range joueur dans la case (i, j). Precondition : coup_legal."""

def gagnant(g):
    """Renvoie "X", "O" ou None. Ne modifie rien."""

def afficher(g):
    """Imprime la grille. Ne calcule rien."""

Trois fonctions se testent par de simples assertions ; la quatrième se vérifie à l'œil, une fois, sur trois grilles. Et le paramètre affiche a disparu : on n'appelle plus afficher quand on ne veut pas afficher.

La règle qu'il faut emporter : une fonction calcule ou affiche, jamais les deux. Ce n'est pas une élégance de style — c'est ce qui rend un projet testable. Un programme dont les calculs sont enfouis dans les fonctions d'affichage ne peut être vérifié qu'en le regardant tourner, c'est-à-dire par la méthode la moins fiable qui soit.