Test d'une représentation d'un échiquier

C'est donc un peu une question aberrante.

J'écris une bibliothèque d'échecs, essentiellement à partir de zéro. Vous pouvez trouver une grande partie du code ici , avec l'intention de l'utiliser pour une interface graphique et / ou un moteur. (Le jeu est Grand Chess mais pour les besoins de cette question, cela n'a pas vraiment d'importance.)

J'écris actuellement des tests unitaires pour vérifier que mes fonctions fonctionnent comme prévu. Et je me demandais s'il y avait une sorte de bibliothèque ou de base de données de positions suggérées pour tester que je peux utiliser et travailler, classées selon qu'elles sont échec et mat, impasse, chèque, légales, illégales, etc.

tl; dr Je recherche une liste de postes pour tester mon code unitaire.

Vous pouvez trouver mes tests actuels ici, je les ajoute tous les quelques jours. Cependant, je veux m'assurer que les tests sont exhaustifs avant de déboguer le code. (La moitié d'entre eux échouent actuellement).

Edit: pour clarifier: je ne recherche pas de tests moteur ("best move"). Je suis à la recherche de tests de représentation du conseil d' administration ("est-ce échec et mat"). J'ai déjà quelques puzzles alignés pour les tests de moteur.

engines database programming

— asibahi
source

Vous codez une variante. Le jeu de données d'échecs standard ne fonctionnera pas pour vous. Je crains donc que vous soyez seul.

— SmallChess

@StudentT je cherche quelque chose à partir duquel je peux commencer. une base de données régulière ferait très bien l'affaire, puisque vous savez, je peux la modifier.

— asibahi

Il y a BEAUCOUP de tels ensembles de test, êtes-vous heureux pour quelque chose comme des exercices tactiques parfaits dans les échecs standard?

— SmallChess

@StudentT Je n'ai rien trouvé via Google, c'est pourquoi je pose la question ici. Toute information serait utile.

— asibahi

Ce que vous voulez tester n'a pas grand-chose à voir avec la représentation du conseil d'administration. Vous aurez envie de tester la représentation du tableau après avoir effectué / défait des mouvements ou importé des positions. Détecter le compagnon / l'impasse nécessite une fonction d'évaluation, et tester la légalité d'un poste devrait être une fonction qui lui est propre et qui a bien plus à faire que de vérifier la représentation du conseil d'administration.

— Queeg

Réponses:

En lisant votre question, ma réaction instinctive est que votre champ d'application est trop compliqué pour les tests unitaires. Je recommande une lecture rapide du livre électronique gratuit Unit Testing Succinctly. Cependant, je n'ai aucune expérience dans l'écriture de code d'échecs (peut-être que vos paradigmes sont différents) - même si je fais des logiciels pour vivre.

Un test unitaire doit être très simple et tester une fonction qui fait 1 seule chose. Ensuite, vous pouvez combiner les fonctions avec une attente raisonnable qu'elles fonctionneront. Par exemple, je m'attendrais à un test unitaire pour chaque pièce afin de déterminer si un mouvement particulier est légal. Un test unitaire pour chaque pièce pour déterminer si elle met le roi en échec. Un test pour chaque pièce pour déterminer où elle attaque, etc.

Tester une position semble être un test unitaire très compliqué et serait beaucoup plus difficile à faire en profondeur. Au lieu de cela, écrivez des tests plus petits par rapport à des fonctions plus petites, puis sachez que ceux-ci fonctionnent individuellement - l'évaluation d'une position n'est qu'une question d'itération sur les fonctions simples.

Si vous voulez tester une position pour un bon coup (non forcé), je pense que les tests unitaires limiteront artificiellement le développement à long terme et la force de votre moteur d'échecs ... un résultat binaire d'un test unitaire forcera votre moteur à faire le même mouvement à chaque fois.

J'envisagerais également d'ajouter des tests unitaires pour le chemin le plus direct vers un partenaire avec des fins de jeu connues. Je voudrais également ajouter des tests unitaires pour traverser des ouvertures connues. Les tests unitaires en milieu de jeu seront beaucoup plus difficiles - peut-être en branchant une position et en évaluant que le moteur produit un résultat utilisable (qui est une réponse binaire).

Pour la question de l'évaluation d'un ensemble de positions pour votre moteur, vous pouvez faire beaucoup mieux en posant cette question sur https://stackoverflow.com/ avec la balise "chess".

— Paul
source

Merci d'avoir répondu. Cependant, comme vous pouvez probablement le constater à partir de la conversation de commentaires sous la question, je ne cherche pas à tester les algorithmes du moteur. Je n'y suis même pas encore arrivé. Je cherche à tester si mon code reconnaît si une position debout sur le plateau est un échec ou une impasse, ou non, ce qui est "juste" en comptant les mouvements légaux et si le roi est en échec. En fait, depuis que j'ai posté cette question, j'ai continué à composer une petite collection de postes à utiliser comme cas de tests unitaires. Je pourrais poster cela comme réponse. (Je suis complètement surpris que quelqu'un ait offert une prime pour cela, tbh.)

— asibahi

Cela ne répond pas à la question.

— SmallChess

En outre, les notes sur les tests unitaires sont fausses.

— SmallChess

@asibahi Je n'avais pas assez de représentants pour poster dans cette section de commentaires, j'ai donc dû ajouter une réponse. Je pense vraiment que vous serez mieux servi dans un forum de programmation (stackexchange) avec cette question. Mais sur ce commentaire ... vous avez déjà identifié des tests unitaires individuels -> Pour chaque test pièce, y a-t-il un mouvement légal. Si l'itération sur ce retourne faux pour chaque pièce, vous avez une impasse, ou échec et mat si vous êtes en échec. Vous n'avez pas besoin d'une vaste collection de postes pour cela. En testant chaque pièce individuellement pour son état actuel, vous pouvez parcourir plusieurs pièces pour évaluer la position.

— Paul

Bien que ce soit une vieille question, j'ai pensé que le concept présenté dans ce blog pourrait être utile: http://scionsoftware.com/blog/write-tests-by-playing-chess

L'idée est que vous joueriez à une partie d'échecs sur une interface graphique et disposez d'un mécanisme pour capturer l'état de l'échiquier en sérialisant dans un fichier.

Vous pouvez nommer ces fichiers selon les cas de test et les insérer dans la méthode de test que vous définissez: IsCheckmate; Est légal; IsDraw

L'une des principales raisons pour lesquelles vous souhaitez utiliser une interface utilisateur naturelle pour créer ces cas de test, en dehors de la facilité de création, est que suffisamment de conditions reposent également sur le nombre de mouvements: roque, en passant, dessiner des conditions.

— SpykeBytes
source

Je ne connais aucune base de données de tests unitaires pour le moteur d'échecs (en général), et oui, écrire un test unitaire exhaustif est presque impossible.

Vous pouvez peut-être explorer des techniques de test alternatives comme les tests basés sur les propriétés (QuickCheck dans Haskell, je ne connais pas l'environnement F # mais il existe certainement quelque chose comme ça pour F #), qui peut générer automatiquement une grande quantité de "position" et les tester en utilisant la propriété que vous avez définie.

J'espère que cela vous aidera un peu :)!

— Sylvain Julmy
source