Tests

Le cours peut être disponible pour les étudiants à tout moment. Il est décomposées en plusieurs types :

• cours
• tutoriel à faire ensemble, prof et élèves font les manipulation en même temps. On purra utiliser un google doc ou des outils plus spécialisés comme https://www.codepile.net ou https://www.pastiebin.com pour partager du code sans avoir besoin de le recopier.
• projet un petit projet de mise en œuvre pour les étudiants. Certains sont des éléments de solutions, d’autre pas

Introduction

Type d’enseignement cours

Nous devons être certains que toutes les méthodes, fonctions ou modules que nous créons sont corrects. On écrira donc des tests pour être moralement sûrs que nos programmes fonctionnent (la plupart du temps une preuve de code est illusoire).

Pour éviter de retaper tous ces tests à chaque modification du code (ce qui arrive souvent lorsqu’un algorithme ou une application est utilisée longtemps) ou à chaque découverte de bug, ils sont conservés dans un fichier à part. Ceci nous permettra d’exécuter ces tests à loisir (c’est à dire très souvent) et d’être sûrs que tous les tests seront exécutés. Ces tests sont dit unitaires et sont essentiels dans toutes les pratiques courantes de code.

De nombreux frameworks de tests existent pour python, le plus connu étant certainement actuellement py.test que nous allons utiliser. Il en existe plein d’autres comme unittest, ou encore nose.

Une très bonne introduction au développement par les tests est l’inusable Test Driven Development: By Example de Kent Beck. Tous les exemples sont en revanche en Java. Sinon en python mais orienté développement web, il y a le bon (mais il faut s’accrocher si on débute) Test-Driven Development with Python de Harry J.w Percival.

Pourquoi

Il faut une façon automatisée et rapide de tester l’intégrité d’un code.

Utilité dans la vraie vie

vérification de code

• on vérifie de toute façon toujours son code une fois écrit. Là on garde les tests effectués :
  • cela permet de gagner du temps lorsque l’on modifie son code (ce que l’on passe son temps à faire)
  • on vérifie que tout fonctionne encore quand le code grossi et que des effets de bords apparaissent
• utiliser ses méthodes permet souvent de mieux les adapter à leurs utilisations. Souvent on effet on pense plus à comment les faires fonctionner et pas à comment ce serait pratique de les utiliser (c’est pourquoi on préconise d’écrire le test avant le code).

production de code

• c’est une méthode pour produire du code (TDD)
• permet de coder à plusieurs : les autres ne peuvent pas casser votre code puisque vos tests doivent passer.

que tester et qui teste

• c’est de la responsabilité du développeur de tester son code. Il sait comment il est fait. Il est non productif de donner cette tâche à une autre personne qui fera des tests plus tard :
  • car on SAIT qu’il y aura des erreurs (qui auraient donc pu être corrigées de suite)
  • des tests ne seront pas effectués (car cette personne ne sais pas comment le code a été fait).
  • le développeur a surement déjà fait des tests pour que son programme tourne c’est donc faire un travail inutile si les tests avaient été sauvées

bilan

Cela permet de ne pas avoir peur. Est-ce que ce code marche ? On lance les tests et 10 secondes plus tard on est rassuré (ou pas).

Utilité en cours

• Algorithmie tableau : pendant l’analyse de l’algorithme au tableau cela permet d’avoir des exemples qui permettent :
  • de montrer le cas général
  • les cas limites (limites d’indices, fin ou début de boucle)
  • vérifier que l’analyse tableau est toujours exacte au passage en code.
• permet sur la fiche de td/tp de donner les cas qui doivent marcher et que les élèves (et vous) puissiez vérifier rapidement que tout fonctionne.
• contrôle : le code des élèves doit passer vos tests.
• les tests sont une façon de voir comment réagit l’algorithme

Séparation des responsabilités dans le code

Un programme informatique se comporte toujours de 3 parties :

• main : l’exécution du programme
• code : les fonctions qui permettent au programme de s’exécuter
• tests : les fonctions qui testent le code

Aucune partie n’est plus importante que l’autre. Les tests doivent être modifiés en même temps que le code ou le main. On ne peut pas (ie. il ne faut pas) écrire 10 lignes de code sans tester, sinon c’est SUR qu’il va y avoir des erreurs (même si on ne fait que recopier du code) : donc on fait du travail pour rien…

On doit donc avoir un moyen de tester ce que l’on fait rapidement. Ceci incite à écrire les programmes sous la forme de petites fonctions faciles à écrire et à tester. Un gros algorithme étant alors une succession d’appels à des fonctions plus petites.

On peut même (c’est comme ça que je code, mais il fat un petit temps d’adapteation pour le faire) écrire ses tests avant le code proprement dit. Ceci à l’avantage de :

• d’utiliser son code avant de l’écrire : on se rend souvent compte que la première idée n’est pas idéale à l’utilisation et on la modifie. On écrit du code pour être utilisé facilement (ce qui est bien)
• de pouvoir tester tout le temps ce qu’on est entrain d’écrire.

On doit toujours retrouver ces trois parties dans un programme. Qu’il soit petit, moyen ou gros.

petits programmes

On peut tout mettre dans un même fichier :

def mon_algo():
    # le code

def test_mon_algo():
    # les tests de l'algo

if __name__ == "__main__":
    # exécution du programme

Le programme principal est en fin de fichier, et exécuté via le truc if __name__ == "__main__":

Les tests s’écrivent en faisant précéder par test_ le nom de la méthdoe à tester. Ils sont exécuté via un framework de test (voir ci-après) qui permet de n’exécuter que les tests et pas le programme.

Souvent utile lorsque la séance de cours consiste à écrire et comrendre un algorithme précis

moyens programmes

Ne nécessiste pas de truc précis, on mets tous les fichiers dans le répertoire principal du projet :

• main.py : un seul fichier qui est l’exécution du programme
• code.py : autant de fichier de code nécessaire. On essaie d’avoir des fichiers de code petit et homogène
• test_code.py : le fichier qui test les fonctions du fichier code On met un fichier de test par ficheir de code.

La encore les testrs sont exécutés automatiquement. C’est facile puisque les fichiers de tests et les tests comencent tous pas test_. C’est comme ça que je procède pour quasi tous les td/tp après le premier où sont expliqués les tests.

Attention : Si on utilise cette méthode, ne mettez pas de tests dans les ficheirs de code, sinon on ne s’y retrouve plus.

gros programmes

Organisation en dossiers. :

• à la racine du projet, un fichier main.pyqui exécute le programme
• un dossier code qui contient tous les fichiers de code (eux-même pouvant être répartis dans des dossiers)
• un dossier tests qui contient tous les fichiers de tests (eux-même pouvant être répartis dans des dossiers)

Pour que python comprennent cette organisation en dossiers, il faut ajouter un fichier __init__.py dans chaque dossier (ce fichier peut être vide). Un dossier comporant un fichier __init__.py est considéré comme un module pour python.

Attention : A reserver aux gros projets, mais à mon sens ce n’est quasi jamais (voir jamais) utile en td/tp.

Comment : introduction à pytest

Type d’enseignement tutoriel

• premiers tests

quoi tester

la règle : Ce qu’il faut pour que vous soyez convaincu que le programme est juste.

Quand on trouvera un bug (ce qui est certain) on ajoutera un test pour vérifier qu’il n’exite plus. Notre programme devient meilleurs, le bug n’apparaitra plus jamais (sinon les tests planteraient).

Au départ on ne sais pas quoi tester. Puis on teste trop. Ce n’est pas grave le but est de tester. Comme les stests évolent avec le code il ne faut pas hésiter à supprimer des tests s’ils ne sont plus nécessaire (car le code à changé par exemple).

Chaque développeur aura ses propres tests. Pour une même fonctions, je n’aurai peut-être pas les même tests que vous. Ce n’est pas grave du moment que les tests permettent d’éviter les même bug.

utilisations des tests

Type d’enseignement tutoriel

• utilisation
• fichiers exemples (au format zip)

à vous

Type d’enseignement projet

On reprend les cas précédents et c’est à vous de trouver et d’écrire les tests.

• projet_tests

Pour aller plus loin.

Si vous avez de petties notions de programmation objet en python, un exemple complet de programmation par les tests :

https://informatique.centrale-marseille.fr/tc_poo/post/tdd_et_test_pattern.html