Spécification et tests en Python : cours de NSI en Première

Tu as déjà écrit des fonctions qui « marchaient » sur ton exemple, puis qui plantaient dès qu'on leur donnait autre chose. Ce chapitre t'apprend à éviter ce piège avec deux outils complémentaires : la spécification, qui dit précisément ce que la fonction doit faire, et les tests, qui vérifient qu'elle le fait vraiment.

En NSI, ces deux notions reviennent partout : dans les exercices de programmation, dans les projets et dans l'épreuve pratique. Le premier exercice de cette épreuve te fait programmer un algorithme du programme, pour lequel une spécification t'est donnée ². Savoir lire une spécification, c'est donc savoir ce qu'on attend de toi.

Le raisonnement se déroule en plusieurs temps :

1. Avant d'écrire le code, tu décris ce que la fonction doit faire (la spécification).
2. Tu écris le code qui réalise cette description.
3. Tu vérifies par des tests que le code respecte la description.

Si tu sautes la première étape, tu ne sais pas ce que tu testes. Si tu sautes la dernière, tu ne sais pas si ton code est correct.

Dans le monde professionnel, la spécification n'apparaît pas au hasard. Une étude préalable décrit d'abord l'existant et les attentes des utilisateurs, puis la spécification reprend ces attentes pour les détailler ⁴. Autrement dit, on part d'un besoin vague (« un logiciel qui gère des notes ») pour aller vers des exigences précises (« la fonction renvoie la moyenne d'une liste de notes »).

La spécification fonctionnelle décrit les tâches que le produit assure et la façon dont il dialogue avec les utilisateurs ou avec d'autres produits ⁴. À notre échelle, c'est le même esprit : on décrit ce que fait la fonction, pas comment elle le fait.

En Python, on place la spécification dans la chaîne de documentation (la docstring), écrite juste sous la ligne def, entre triples guillemets. Elle sert de contrat entre la personne qui écrit la fonction et celle qui l'utilise.

Les annotations de type donnent une version compacte de la spécification des types :

def moyenne(t: list[float]) -> float:
    ...

Elles documentent le programme, mais Python ne les impose pas à l'exécution. Elles ne remplacent donc ni la docstring (qui exprime la précondition et la postcondition) ni les tests.

Concrètement, un test se compose de trois éléments :

• une entrée (les arguments donnés à la fonction) ;
• une sortie attendue, déduite de la spécification et non du code ;
• une comparaison entre la sortie obtenue et la sortie attendue.

Si les deux valeurs sont égales, le test réussit. Sinon il échoue, et tu sais qu'il existe un défaut, soit dans le code, soit dans ton test, soit dans la spécification.

L'intérêt est de tester chaque morceau séparément. La personne qui programme examine un module sans tenir compte du reste, afin de s'assurer qu'il répond aux spécifications fonctionnelles et se comporte bien quelles que soient les circonstances ⁵. Cette vérification est jugée indispensable surtout pour les applications critiques ⁵.

L'avantage pratique est immédiat : quand un programme de 200 lignes plante, tu ne sais pas où chercher. Si chaque fonction a été testée séparément, tu sais que l'erreur se trouve sans doute dans l'assemblage, ou dans la fonction dont les tests étaient trop pauvres.

Dans les langages courants, il existe de nombreux cadriciels (frameworks) qui facilitent l'écriture des tests unitaires ⁵. En NSI, tu peux te contenter d'assert et d'une fonction de test qui regroupe plusieurs vérifications :

def test_maximum():
    assert maximum([3, 8, 5]) == 8
    assert maximum([4]) == 4
    assert maximum([-5, -2, -9]) == -2
    assert maximum([7, 7, 7]) == 7
    print("maximum : tous les tests passent")

test_maximum()

Réussir cinq tests ne prouve pas que ton code est juste. Un test qui échoue montre qu'une erreur existe ; un test qui réussit établit seulement que le code est correct pour cette entrée. La qualité d'un jeu de test dépend donc de la variété des cas choisis.

Les tests doivent refléter la spécification. Mieux vaut donc les rédiger en premier, puis faire en sorte que le code les satisfasse, plutôt que de coder d'abord et de risquer que le code oriente la rédaction des tests ⁵. Cette démarche est défendue par les partisans de la méthode TDD (Test Driven Development) ⁵.

La première étape du modèle proposé consiste à écrire une fonction de test qui attend un résultat fixé par la spécification. Comme elle appelle du code encore inexistant, elle échoue forcément ; elle sert alors à définir ce que l'on teste ⁵.

On peut aussi utiliser assert pour contrôler les préconditions au début d'une fonction. Cela transforme une erreur silencieuse en erreur explicite, plus facile à comprendre.

def moyenne(t):
    """Renvoie la moyenne des éléments du tableau t (non vide)."""
    assert len(t) > 0, "le tableau ne doit pas être vide"
    return sum(t) / len(t)

Si quelqu'un appelle moyenne([]), le message indique clairement quelle exigence n'est pas respectée.

Dans le premier exercice de l'épreuve pratique, tu programmes un algorithme nommé au programme et sans difficulté particulière, à partir d'une spécification qui t'est donnée ². L'énoncé peut joindre des exemples avec leurs résultats attendus ². Une autre forme consiste à compléter un programme à trous afin qu'il réponde à la spécification ².

Dans tous les cas, la méthode est la même : lire la spécification jusqu'au bout, repérer les entrées et la sortie, regarder les exemples du jeu de test, puis écrire le code et le tester.