Documentation on unit tests
This commit is contained in:
parent
d738029335
commit
6d786c7358
@ -1,12 +1,50 @@
|
|||||||
Exécution des tests
|
Exécution des tests
|
||||||
===================
|
===================
|
||||||
|
|
||||||
.. note::
|
|
||||||
La documentation va être revue ici.
|
|
||||||
|
|
||||||
Les tests sont gérés par ``pytest`` dans le module ``squirrelbattle.tests``.
|
|
||||||
|
|
||||||
``tox`` est un outil permettant de configurer l'exécution des tests. Ainsi, après
|
``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``,
|
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``
|
il vous suffit d'exécuter ``tox -e py3`` pour lancer les tests et ``tox -e linters``
|
||||||
pour vérifier la syntaxe du code.
|
pour vérifier la syntaxe du code.
|
||||||
|
|
||||||
|
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.
|
||||||
|
Loading…
Reference in New Issue
Block a user