2020-11-19 21:32:25 +00:00
|
|
|
Exécution des tests
|
|
|
|
===================
|
|
|
|
|
|
|
|
``tox`` est un outil permettant de configurer l'exécution des tests. Ainsi, après
|
|
|
|
installation de tox dans votre environnement virtuel via ``pip install tox``,
|
|
|
|
il vous suffit d'exécuter ``tox -e py3`` pour lancer les tests et ``tox -e linters``
|
|
|
|
pour vérifier la syntaxe du code.
|
2021-01-10 10:30:04 +00:00
|
|
|
|
|
|
|
Tests unitaires
|
|
|
|
---------------
|
|
|
|
|
|
|
|
Les tests sont gérés par ``pytest`` dans le module ``squirrelbattle.tests``.
|
|
|
|
Le module ``pytest-cov`` permet de mesurer la couverture du code.
|
|
|
|
Pour lancer les tests, il suffit de lancer ``tox -e py3`` ou de manière équivalente
|
|
|
|
``pytest --cov=squirrelbattle/ --cov-report=term-missing squirrelbattle/``
|
|
|
|
|
|
|
|
L'intégration continue lance les tests pour les versions de Python de 3.6 à 3.10,
|
|
|
|
sur une distribution Alpine Linux.
|
|
|
|
|
|
|
|
Chaque partie du code est testée unitairement, pour obtenir une couverture
|
|
|
|
maximale et assurer un bon fonctionnement. En particulier, le jeu est lancé
|
|
|
|
en commençant sur une carte déterministe (non générée aléatoirement) chargée
|
|
|
|
depuis ``assets/example_map.txt``, sur laquelle sont placés des ennemis et objets
|
|
|
|
avec lesquels le joueur doit interagir. On vérifie qu'à chaque touche appuyée,
|
|
|
|
il se passe le bon comportement. Le comportement des différents menus est
|
|
|
|
également testé.
|
|
|
|
|
|
|
|
L'environnement de test ne disposant pas a priori d'un terminal, le jeu est
|
|
|
|
conçu pour fonctionner sans support graphique, avec un terminal fictif où les
|
|
|
|
primitives de curses sont implémentées pour ne rien faire. On ne peut alors
|
|
|
|
pas s'assurer du bon fonctionnement de curses.
|
|
|
|
|
|
|
|
De plus, une très fine partie du code est ignorée lors de la couverture, ce
|
|
|
|
qui correspond à la phase d'initialisation du terminal et à la boucle infinie
|
|
|
|
qui reçoit les touches de l'utilisateur, qu'il est alors impossible de tester
|
|
|
|
unitairement.
|
|
|
|
|
|
|
|
|
|
|
|
Analyseur syntaxique
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
``flake8`` est utilisé en guise d'analyseur syntaxique. Il vérifie si le code
|
|
|
|
est bien formatté afin d'assurer une certaine lisibilité. En particulier,
|
|
|
|
il vérifie l'indentation, si chaque variable est bien utilisée, s'il n'y a pas
|
|
|
|
d'import inutile et s'ils sont dans l'ordre lexicographique, si chaque ligne
|
|
|
|
fait au plus 80 caractères et si la signature de chaque fonction est bien
|
|
|
|
spécifiée.
|
|
|
|
|
|
|
|
Pour lancer l'analyse, ``tox -e linters`` suffit. L'intégration continue
|
|
|
|
effectue cette analyse à chaque commit.
|