$course$/QCM de NSI/Première/Tests et débogage Tester un programme : assertions, jeux d'essais,
tests unitaires, cas limites. Déboguer : lecture de
la trace d'erreurs, instructions print de
débogage, débogueur interactif, isolement de bugs,
réduction au cas minimal.

]]> Tests et débogage — Q01 : Notion de test Qu'appelle-t-on un test dans le
contexte du logiciel ?

]]> Une bonne pratique consiste à
tester systématiquement ses
fonctions, en particulier dans les
parties critiques du programme. Un
projet sans tests est très
fragile.

]]> 1.0 0.0 0 true true abc Une vérification automatique qu'un programme se comporte comme attendu sur des entrées choisies

]]> Un test fournit une entrée connue
et compare la sortie obtenue à la
sortie attendue. Cela permet de
détecter aussi bien les
régressions que les bugs
nouveaux.

]]> Un type particulier de variable

]]> Un test n'est pas une variable.
C'est une procédure de
vérification.

]]> Une question à choix multiple posée à l'utilisateur

]]> Cette interprétation littérale est
sans rapport avec la notion
informatique de test logiciel,
qui vise à vérifier le bon
fonctionnement d'un programme.

]]> Un avertissement émis par le langage Python

]]> Un avertissement est un message
envoyé pendant l'exécution, sans
comparaison à une valeur attendue.
Ce n'est pas un test.

]]> Tests et débogage — Q02 : Instruction assert Que fait l'instruction assert
condition en Python ?

]]> Un usage typique :
assert n > 0, "n doit être
positif". Le message après la
virgule apparaît dans l'erreur
affichée, ce qui aide au
débogage.

]]> 1.0 0.0 0 true true abc Si la condition est fausse, elle lève une exception AssertionError ; sinon, elle ne fait rien

]]> C'est très utile pour vérifier
des invariants. Lorsqu'une
assertion échoue, le programme
s'arrête, ce qui permet de
détecter les bugs au plus tôt.

]]> Elle affiche la condition à l'écran

]]> L'instruction assert n'affiche
rien lorsque la condition est
vraie. Elle ne lève une erreur
que dans le cas contraire.

]]> Elle convertit la condition en booléen

]]> La condition est déjà évaluée
comme un booléen avant l'appel à
assert. La conversion en tant
que telle se fait avec
bool(...).

]]> Elle ne fonctionne qu'en mode débogage

]]> Cette description est inexacte.
Les assertions sont actives par
défaut, et désactivées seulement
si le programme est lancé avec
l'option python -O.

]]> Tests et débogage — Q03 : Test unitaire Qu'est-ce qu'un test unitaire ?

]]> Une organisation classique des
tests forme une pyramide :
beaucoup de tests unitaires (très
rapides), moins de tests
d'intégration (plus lents mais
utiles) et très peu de tests de
bout en bout (lents et fragiles).

]]> 1.0 0.0 0 true true abc Un test sans coût

]]> Cette interprétation littérale
du mot « unitaire » est
fantaisiste.

]]> Un test qui couvre tout le programme

]]> Un test qui couvre l'ensemble du
programme s'appelle un test
d'intégration ou un test
système, et non un test
unitaire.

]]> Un test qui dure très longtemps

]]> C'est plutôt l'inverse. Les tests
unitaires sont conçus pour être
rapides, ciblés et automatisés.

]]> Un test qui vérifie le comportement d'une seule fonction (une « unité » de code) sur des entrées spécifiques

]]> Les tests unitaires sont
rapides, ciblés et automatisés.
Ils permettent d'isoler les
bugs : on identifie précisément
quelle fonction se comporte
mal.

]]> Tests et débogage — Q04 : Exemple de test Quelle ligne teste que carre(3)
== 9 ?

]]> L'instruction assert est rapide
à écrire et lisible. Pour des
tests plus structurés, avec
rapports détaillés, on préfère le
module unittest ou la
bibliothèque pytest.

]]> 1.0 0.0 0 true true abc if carre(3) != 9: print("erreur")

]]> Cette ligne effectue bien une
vérification, mais elle
n'interrompt pas le programme
en cas d'échec. L'instruction
assert est plus idiomatique
dans un contexte de test.

]]> assert carre(3) == 9

]]> Si carre(3) ne vaut pas 9,
l'assertion échoue et le
programme s'arrête. Sinon, le
programme continue
silencieusement.

]]> carre(3)

]]> Cette ligne exécute simplement
la fonction sans rien vérifier.
Aucune comparaison n'est
effectuée.

]]> test carre(3) == 9

]]> Cette syntaxe n'existe pas en
Python. Le mot-clé test
n'est pas reconnu par le
langage.

]]> Tests et débogage — Q05 : Erreur Python Quand Python lève une erreur, où
regarder pour comprendre ce qui se
passe ?

]]> Quelques erreurs fréquentes :
NameError (variable inconnue),
TypeError (incompatibilité de
types), IndexError (indice hors
des bornes), ValueError (valeur
inappropriée pour une opération).

]]> 1.0 0.0 0 true true abc Le code source du module Python lui-même

]]> Ce serait à faire en dernier
recours. La plupart du temps,
l'erreur vient du code
utilisateur, pas de
l'interpréteur.

]]> Les paramètres du système d'exploitation

]]> La trace d'erreur Python est
locale au programme. Le
système d'exploitation n'est
pas concerné.

]]> Sur Internet, en cherchant un message proche

]]> Cette démarche peut compléter
l'analyse, mais ce n'est pas
la première chose à faire. Il
faut commencer par la trace
d'erreur affichée par Python.

]]> La trace d'erreur affichée par Python, qui indique le fichier, la ligne concernée et le type d'erreur

]]> On lit la trace d'erreur du bas
vers le haut. La dernière ligne
donne en général le type
d'erreur et le message
associé.

]]> Tests et débogage — Q06 : Instruction print de débogage À quoi sert un appel à print dans
un objectif de débogage ?

]]> Avantages : la fonction print
est simple et fonctionne partout.
Inconvénient : il faut penser à
retirer ces affichages après le
débogage. Pour un suivi plus
sophistiqué, on peut utiliser le
module logging ou un débogueur
interactif comme pdb.

]]> 1.0 0.0 0 true true abc À empêcher d'écrire d'autres lignes de code

]]> Cette description ne correspond
à aucun usage réel de print.

]]> À encoder des données en hexadécimal

]]> La fonction print ne réalise
aucune conversion automatique
en hexadécimal.

]]> À afficher la valeur d'une variable à un moment précis du programme, pour suivre son déroulement

]]> C'est une technique simple mais
efficace. Pour suivre la valeur
de x à l'intérieur d'une
boucle, on peut écrire
print(f"x = {x}").

]]> À ralentir intentionnellement le programme

]]> Un excès de print peut
effectivement ralentir un
programme, mais ce n'est jamais
l'objectif recherché.

]]> Tests et débogage — Q07 : Notion de bug Qu'est-ce qu'un bug ?

]]> Il faut distinguer plusieurs
notions : un bug signifie
que le code ne fait pas ce qu'il
doit ; une erreur d'exécution
survient quand le programme
plante ; une erreur de
spécification signifie que la
définition même du
comportement attendu est
incorrecte. Cette dernière est
la plus difficile à corriger.

]]> 1.0 0.0 0 true true abc Une erreur ou un comportement non conforme aux spécifications du programme

]]> Le terme est historique : il
provient d'un véritable insecte
retrouvé en 1947 dans les
relais d'une machine analysée
par Grace Hopper. La trace de
cet incident est encore
conservée.

]]> Une fonctionnalité que l'utilisateur n'a pas demandée

]]> Cette description est une
plaisanterie courante (« ce
n'est pas un bug, c'est une
fonctionnalité »), mais elle
ne correspond pas à la
définition technique.

]]> Une nouvelle version d'un logiciel

]]> Une nouvelle version peut
comporter des bugs, mais elle
n'est pas elle-même un bug.

]]> Un type particulier de mémoire

]]> Un bug n'a aucun rapport avec
la mémoire d'un ordinateur.

]]> Tests et débogage — Q08 : Jeu d'essais Qu'est-ce qu'un jeu d'essais ?

]]> Un bon jeu d'essais détecte les
régressions. Si l'on modifie le
code et que tous les tests
continuent à passer, on peut
avoir confiance. Si un test
échoue, on sait précisément quoi
corriger.

]]> 1.0 0.0 0 true true abc Un test choisi au hasard

]]> Un jeu d'essais est conçu de
manière réfléchie, et non tiré
au hasard.

]]> Un ensemble d'entrées prévues, chacune accompagnée de sa sortie attendue, qui couvre les cas typiques et les cas limites de la fonction

]]> Un bon jeu d'essais couvre les
cas normaux, les cas limites
(par exemple liste vide, liste
d'un seul élément, valeurs
extrêmes) et les cas d'erreur
(entrée invalide). Plus la
couverture est large, plus le
test est robuste.

]]> Un manuel d'utilisation du programme

]]> La documentation et les jeux
d'essais sont deux notions
distinctes.

]]> Une collection de jeux vidéo

]]> Cette interprétation littérale
du mot « jeu » est sans
rapport avec son sens
informatique.

]]> Tests et débogage — Q09 : Lire une trace d'erreur `
File "main.py", line 5, in <module>
print(liste[5])
IndexError: list index out of range
`
Que dit cette trace d'erreur ?

]]> Le réflexe à acquérir : lire le
type de l'erreur (qui donne
la nature du bug), puis la
ligne indiquée (qui en
donne l'emplacement). C'est
systématique.

]]> 1.0 0.0 0 true true abc À la ligne 5 de main.py, on tente d'accéder à liste[5] alors que cet indice n'existe pas (la liste est trop courte)

]]> Le message
IndexError: list index out of
range signifie un accès à un
indice hors des bornes. La
cause typique est une mauvaise
estimation de la taille de la
liste.

]]> La ligne 5 contient une variable non définie

]]> Cette description correspond à
une NameError, et non à une
IndexError.

]]> Il s'agit d'une erreur de syntaxe

]]> Une erreur de syntaxe se
présente sous la forme d'une
SyntaxError, et non d'une
IndexError.

]]> Aucun problème n'est signalé

]]> La trace contient bien une
erreur, indiquée par
IndexError.

]]> Tests et débogage — Q10 : Isoler un bug Pour comprendre l'origine d'un bug
dans un programme, quelle démarche
est la plus efficace en première
approche ?

]]> La discipline du cas de test
minimal est l'une des bases du
débogage. Elle permet aussi
d'écrire un test de non-régression
compact, qui protégera contre la
réapparition du bug à l'avenir.

]]> 1.0 0.0 0 true true abc Ignorer le bug s'il n'apparaît qu'à l'occasion

]]> Un bug intermittent, surtout,
ne s'efface pas en l'ignorant.
Il finit par réapparaître au
plus mauvais moment. Au
contraire, il faut chercher
activement à le reproduire.

]]> Réduire l'entrée problématique au cas le plus simple qui reproduit encore le bug

]]> C'est l'idée du cas de test
minimal. Si un programme plante
sur une liste de mille
éléments, essayer d'abord avec
dix, puis avec cinq, puis avec
deux, en gardant à chaque fois
la propriété qui fait planter.
On obtient un exemple court qui
aide à localiser le bug et à
écrire un test de régression.

]]> Réécrire l'intégralité du programme depuis zéro

]]> Cette démarche est risquée et
peu économique. Elle introduit
souvent de nouveaux bugs sans
comprendre l'origine du bug
initial.

]]> Multiplier la taille de l'entrée jusqu'à trouver une régularité

]]> C'est l'inverse de la démarche
utile. Plus l'entrée est
grande, plus il est difficile
d'identifier ce qui déclenche
précisément le bug.

]]> Tests et débogage — Q11 : Module unittest Quel module de la bibliothèque
standard de Python permet d'écrire
des tests structurés ?

]]> Pour exécuter les tests, on
utilise la commande python -m
unittest. Pour un débutant, des
assert directs peuvent
suffire. Pour un projet
sérieux, mieux vaut adopter
unittest ou pytest.

]]> 1.0 0.0 0 true true abc debug

]]> Aucun module de ce nom
n'existe dans la bibliothèque
standard de Python.

]]> unittest

]]> C'est le module standard pour
les tests unitaires en
Python. On définit des
classes héritant de
TestCase et l'on écrit des
méthodes dont le nom commence
par test_. Une alternative
très populaire est la
bibliothèque pytest, plus
simple d'usage.

]]> assert_module

]]> Aucun module de ce nom
n'existe dans la bibliothèque
standard.

]]> tests

]]> Aucun module de ce nom
n'existe non plus dans la
bibliothèque standard.

]]> Tests et débogage — Q12 : La bibliothèque pytest Pourquoi la bibliothèque pytest
est-elle si populaire ?

]]> Un test minimal écrit avec
pytest :

`python
def test_carre():
assert carre(3) == 9

Pour lancer les tests, on
exécute simplement la commande
pytest, qui découvre
automatiquement les fonctions
dont le nom commence par
test_`.

]]> 1.0 0.0 0 true true abc Pour sa syntaxe simple (un assert valeur == attendu suffit, pas besoin de classes), ses fixtures et son écosystème de greffons

]]> Cette bibliothèque simplifie
considérablement l'écriture
des tests par rapport au
module unittest. Elle est
devenue le standard de fait
dans le monde Python
moderne.

]]> Parce qu'elle est obligatoire dans tout projet Python

]]> Aucune obligation n'existe.
La bibliothèque pytest est
facultative, même si très
recommandée.

]]> Parce qu'elle génère automatiquement le code des tests

]]> La bibliothèque pytest ne
génère pas automatiquement le
code des tests : c'est au
développeur de les écrire.

]]> Parce qu'elle est plus rapide à l'exécution

]]> La rapidité d'exécution n'est
pas son atout principal. Sa
force vient de la simplicité
d'écriture des tests.

]]> Tests et débogage — Q13 : Identifier un bug `python
def somme(liste):
total = 0
for i in range(1, len(liste)):
total += liste[i]
return total
`
Quel bug contient cette fonction ?

]]> Les bugs de décalage d'indice
sont très fréquents. Il faut
toujours tester avec des listes
simples ([], [1],
[1, 2]) pour les détecter.
Un bon test serait par exemple
assert somme([1, 2, 3]) == 6.

]]> 1.0 0.0 0 true true abc Aucun bug n'est présent

]]> Un bug existe bien dans cette
fonction, comme expliqué dans
la bonne réponse.

]]> La fonction ne renvoie aucune valeur

]]> La fonction se termine bien
par return total, donc
elle renvoie une valeur.

]]> La syntaxe est incorrecte

]]> Le code est syntaxiquement
valide. Le bug est purement
logique.

]]> La boucle commence à l'indice 1 au lieu de 0, donc l'élément liste[0] est ignoré

]]> C'est un bug classique de
décalage d'indice. Pour
la liste [1, 2, 3], la
fonction renvoie 5 au lieu
de 6. Un test sur un cas
simple permettrait de le
détecter.

]]> Tests et débogage — Q14 : Lire la trace d'erreur Dans une trace d'erreur à plusieurs
niveaux, où trouve-t-on en général
la cause initiale du bug ?

]]> Pour lire une trace : commencer
par la fin, qui indique le type
d'erreur, puis remonter
jusqu'au code qu'on a soi-même
écrit. Les premières lignes,
souvent dans des bibliothèques,
sont rarement le bon point
d'entrée.

]]> 1.0 0.0 0 true true abc Au milieu de la trace

]]> Aucune position particulière
au milieu n'est privilégiée.
La cause initiale se lit en
bas de la trace.

]]> Au hasard dans la trace

]]> La position du message
d'erreur n'a rien d'aléatoire :
il se trouve toujours à la
fin de la trace.

]]> En haut de la trace

]]> C'est plutôt l'inverse. Le
message d'erreur le plus
précis se trouve en bas de
la trace.

]]> La dernière ligne (en bas), qui indique le type et le message d'erreur, et la ligne immédiatement au-dessus, qui pointe l'endroit dans votre code

]]> Python affiche la pile des
appels de fonctions dans
l'ordre chronologique, et le
message d'erreur tout en
bas. La ligne la plus utile
est généralement celle qui
renvoie à votre propre code.

]]> Tests et débogage — Q15 : Reproduire un bug Pour résoudre un bug, qu'est-ce qui
est essentiel à faire en
premier ?

]]> L'adage classique est :
« si l'on ne peut pas
reproduire le bug, on ne peut
pas le corriger ». Une fois la
reproduction obtenue, on peut
réduire l'entrée au cas minimal
qui déclenche encore le bug,
puis corriger.

]]> 1.0 0.0 0 true true abc Demander à un collègue de regarder le code

]]> Cela peut aider dans un
second temps, mais ni un
humain ni un assistant
automatique ne peuvent
diagnostiquer un bug sans
pouvoir le reproduire.

]]> Réécrire le code suspect

]]> La réécriture n'est pas la
première étape. Il faut
d'abord pouvoir observer le
bug pour pouvoir vérifier
ensuite la correction.

]]> Réinstaller l'interpréteur Python

]]> Cette opération est rarement
nécessaire. La cause d'un
bug se trouve presque
toujours dans le code lui-même.

]]> Le reproduire : trouver une entrée minimale qui déclenche systématiquement le bug

]]> Un bug intermittent est très
difficile à corriger. La
reproduction est la première
étape, et permet d'écrire un
test de régression.

]]> Tests et débogage — Q16 : Débogueur Qu'est-ce qu'un débogueur ?

]]> Pour activer pdb, on lance la
commande python -m pdb
script.py, ou on insère
breakpoint() dans le code
(depuis Python 3.7). Quelques
commandes utiles : n pour
passer à la ligne suivante,
s pour entrer dans une
fonction, c pour continuer,
et p variable pour afficher
la valeur d'une variable.

]]> 1.0 0.0 0 true true abc Un compilateur

]]> Un compilateur transforme du
code source en code
exécutable. Il n'a aucun
rapport avec le débogage
interactif.

]]> Un outil qui permet d'exécuter pas à pas, d'inspecter les variables, de poser des points d'arrêt et de remonter la pile des appels

]]> Plusieurs outils existent :
pdb en ligne de commande,
ou les débogueurs intégrés
aux environnements de
développement comme VS Code
ou PyCharm. Tous sont
puissants pour comprendre
des bugs complexes.

]]> Un antivirus

]]> Un antivirus protège contre
les logiciels malveillants ;
il n'a rien à voir avec le
débogage de programmes.

]]> Un fichier de journalisation

]]> Un débogueur est un outil
interactif, et non un fichier
stocké sur le disque.

]]> Tests et débogage — Q17 : Couverture de tests Que mesure la couverture de
tests ?

]]> Attention : une couverture de
100 \% ne garantit pas
l'absence de bugs. On peut
passer dans toutes les lignes
sans pour autant tester tous
les comportements. C'est
néanmoins une base utile.

]]> 1.0 0.0 0 true true abc La proportion de lignes (ou de branches) du code qui sont effectivement exécutées par les tests

]]> C'est un indicateur de
qualité des tests. Une
couverture de 80 \% est
bien meilleure qu'une
couverture de 30 \%.
L'outil coverage.py
permet de la mesurer en
Python.

]]> La taille en octets du programme

]]> La taille du programme n'a
aucun rapport avec la
couverture des tests.

]]> Le nombre total de tests écrits

]]> La couverture ne se réduit
pas à un comptage des tests.
Elle s'intéresse à la part
du code effectivement
parcourue.

]]> La performance d'exécution du programme

]]> La couverture n'a rien à
voir avec la performance.
C'est une mesure de la
qualité de la suite de
tests.

]]> Tests et débogage — Q18 : Test de régression Qu'est-ce qu'un test de
régression ?

]]> Une discipline classique
consiste en un cycle « rouge
puis vert » : on écrit
d'abord un test qui reproduit
le bug et qui échoue (état
« rouge »), puis on corrige
le code jusqu'à ce que le
test passe (état « vert »).

]]> 1.0 0.0 0 true true abc Un test qui revient en arrière dans le code

]]> Cette interprétation
littérale du mot
« régression » ne
correspond pas au sens
technique de
l'expression.

]]> Un test qui échoue à chaque exécution

]]> Un test de régression doit
au contraire passer après
la correction. S'il échoue
systématiquement, c'est que
la correction n'a pas été
faite, ou qu'elle a été
défaite.

]]> Un test ajouté après avoir corrigé un bug, dont le rôle est de vérifier que ce bug ne réapparaisse pas dans le futur

]]> C'est une pratique
essentielle. Pour chaque
bug corrigé, il est
recommandé d'ajouter un
test qui aurait permis de
le détecter. Cela protège
contre les régressions
futures.

]]> Un test sur l'ancienne version du code

]]> Un test de régression
s'exécute sur la version
actuelle du code, pas sur
une ancienne. Son rôle est
de prévenir le retour d'un
bug ancien.

]]> Tests et débogage — Q19 : Module logging Pourquoi préfère-t-on le module
logging à la fonction print
pour le débogage en production ?

]]> Exemple d'utilisation typique :

`python
import logging
logging.basicConfig(level=logging.DEBUG)
logging.debug("valeur de x : %s", x)

Ce module est plus puissant
que print`, au prix d'un
léger surcoût syntaxique.

]]> 1.0 0.0 0 true true abc Parce que la fonction print n'existe pas en Python

]]> La fonction print existe
bel et bien et reste utile,
notamment pour
l'apprentissage.

]]> Pour pouvoir activer ou désactiver les messages, choisir leur niveau de gravité (debug, info, warning, error), les rediriger vers un fichier, etc.

]]> Le module logging est
conçu pour la production.
Il offre une configuration
centralisée, plusieurs
niveaux de gravité, un
formatage riche et plusieurs
destinataires possibles
(console, fichier, réseau).

]]> Parce que le module logging est obligatoire

]]> L'usage du module est
facultatif, mais il est
fortement recommandé pour
les programmes destinés à
la production.

]]> Pour gagner de l'espace en mémoire

]]> L'avantage du module
logging n'est pas une
économie de mémoire.
C'est avant tout une
question de souplesse et
de configurabilité.

]]> Tests et débogage — Q20 : Écrire les tests avant le code Quel est l'avantage principal
d'écrire les tests avant le
code (approche dite de
développement piloté par les
tests) ?

]]> Le cycle est le suivant : on
écrit d'abord un test qui
échoue ; on écrit ensuite le
code minimal qui le fait
passer ; on retravaille
enfin la structure du code,
en conservant les tests
verts. Ce cycle se répète
sur de petites unités, à un
rythme fréquent.

]]> 1.0 0.0 0 true true abc Elle oblige à clarifier la spécification avant l'implémentation, et garantit que la fonction sera testable et fera bien ce qui est attendu

]]> On écrit la spécification
sous une forme exécutable
(le test), ce qui contraint
à réfléchir précisément
aux comportements attendus
avant de coder.

]]> Le code est plus rapide à écrire dès le départ

]]> Cette approche n'est pas
plus rapide au démarrage,
et exige même un certain
temps d'apprentissage. Son
intérêt se mesure surtout
à moyen terme, sur la
qualité et la fiabilité
du code produit.

]]> Elle dispense d'écrire des commentaires

]]> Aucun rapport. Les
commentaires gardent leur
utilité pour expliquer
les intentions et les
choix de conception.

]]> Elle permet d'éviter complètement les bugs

]]> Cette affirmation est trop
optimiste. Aucune méthode
ne supprime tous les bugs.
Les tests réduisent leur
fréquence et facilitent
leur détection précoce.

]]> Tests et débogage — Q21 : Bug intermittent Un bug se produit parfois,
sans que l'on sache prévoir
quand. Que faire ?

]]> Causes typiques
d'intermittence : exécution
concurrente (fils
d'exécution, parallélisme),
mémoire non initialisée,
état global partagé, ordre
des éléments dans un
dictionnaire (avant Python
3.7).

]]> 1.0 0.0 0 true true abc Multiplier les journaux d'exécution, ajouter des assertions, et étudier ce qui change entre les exécutions où le programme fonctionne et celles où il échoue (synchronisation, ordre, données d'entrée)

]]> Les bugs intermittents
révèlent souvent des
courses critiques, des
problèmes de
synchronisation, ou des
dépendances cachées entre
parties du programme.

]]> Réinstaller Python

]]> Cette opération est très
rarement la cause, et ne
devrait être tentée qu'en
dernier recours.

]]> Acheter un nouvel ordinateur

]]> Cette interprétation
littérale est sans rapport
avec le débogage.

]]> Ignorer le bug

]]> C'est une mauvaise pratique.
Un bug ignoré finit
toujours par revenir, et
souvent au pire moment.

]]> Tests et débogage — Q22 : Stratégie globale Devant un bug, quelle est la
bonne stratégie générale à
adopter ?

]]> Discipline : ne jamais
corriger un bug sans avoir
réussi à le reproduire, et
ne jamais corriger sans
ajouter ensuite un test de
régression. Sinon, le bug
finira par réapparaître,
et le temps gagné au
départ sera perdu plus
tard.

]]> 1.0 0.0 0 true true abc Demander une mise à jour du langage Python

]]> Une telle mise à jour est
extrêmement rarement la
solution à un bug
applicatif.

]]> Reproduire le bug, isoler la cause (en réduisant l'entrée au cas minimal), corriger, puis ajouter un test de régression

]]> C'est une méthodologie
éprouvée. Sauter une étape,
en particulier la dernière,
garantit que le bug
finira par réapparaître.

]]> Réécrire intégralement le programme

]]> Cette démarche est risquée :
elle peut introduire de
nouveaux bugs et masque
l'origine du problème
initial.

]]> Désactiver les tests existants

]]> Cette démarche est
contre-productive. Les
tests sont précisément
l'outil principal pour
détecter et corriger les
bugs.

]]> Tests et débogage — Q23 : Test mal écrit Quel est le problème avec ce
test ?
`python
assert chercher([1, 2, 3], 2)
`

]]> Piège des tests laxistes :
ils passent quand ils ne
devraient pas, et laissent
passer des bugs. Il faut
toujours vérifier des
valeurs précises, et non
simplement l'absence
d'erreur.

]]> 1.0 0.0 0 true true abc La syntaxe est invalide

]]> Le code est syntaxiquement
valide. Le défaut est
purement sémantique : le
test n'est pas assez
précis.

]]> La fonction chercher n'existe pas

]]> On suppose que la fonction
existe et est définie
quelque part dans le code.
Le problème ne tient pas
à son existence.

]]> Aucun problème particulier

]]> Ce test contient en réalité
un défaut subtil mais
important, comme expliqué
dans la bonne réponse.

]]> Il vérifie seulement que chercher renvoie une valeur considérée comme vraie au sens booléen, mais pas que l'indice est correct. La fonction pourrait renvoyer 0 (qui est le bon indice mais évalue à False) ou 999 (qui est faux, mais évalue à True)

]]> Ce test est trop laxiste.
On préfère écrire
assert chercher([1, 2, 3],
2) == 1, qui vérifie
précisément la valeur
renvoyée.

]]> Tests et débogage — Q24 : Tests et débogage Quelle est la
complémentarité entre tests
et débogage ?

]]> Une démarche idéale combine
les deux activités : on
écrit d'abord des tests qui
trouvent un bug ; on
débogue ensuite pour
localiser, comprendre et
corriger ; on ajoute enfin
un test de régression pour
empêcher la résurgence du
bug.

]]> 1.0 0.0 0 true true abc L'une remplace l'autre

]]> Ces activités sont
complémentaires : ni les
tests ni le débogage ne
peuvent se passer l'un de
l'autre dans un projet
sérieux.

]]> Les tests trouvent les bugs (sur les cas testés), le débogage localise et corrige un bug déjà repéré

]]> Ce sont deux phases
distinctes mais
complémentaires. Tester,
c'est investir pour
détecter ; déboguer, c'est
investiguer pour corriger.

]]> Le débogage permet d'éviter d'écrire des tests

]]> C'est l'inverse : un bon
ensemble de tests permet
de détecter rapidement un
bug et de réduire le
temps passé à le déboguer.

]]> Les deux activités sont identiques

]]> Ces activités diffèrent
par leur objectif et leur
déroulement, comme
expliqué dans la bonne
réponse.

]]> Tests et débogage — Q25 : Synthèse Parmi les affirmations suivantes
sur les tests et le débogage,
laquelle est fausse ?

]]> Citation d'Edsger Dijkstra :
« Program testing can be
used to show the presence of
bugs, but never to show
their absence. » Pour
garantir formellement
l'absence de bugs, il
faudrait recourir à une
preuve mathématique, ce qui
reste rarement praticable
sur du code réel.

]]> 1.0 0.0 0 true true abc Réduire l'entrée problématique au cas le plus simple qui reproduit le bug aide à localiser sa cause

]]> Cette affirmation est
correcte. C'est l'une des
techniques de base pour
isoler un bug.

]]> La trace d'erreur indique le type d'erreur et la ligne où elle s'est produite

]]> Cette affirmation est
correcte. C'est même son
rôle principal.

]]> Un test unitaire vérifie une seule fonction de manière isolée

]]> Cette affirmation est
correcte. C'est même la
définition d'un test
unitaire.

]]> Les tests garantissent l'absence de bugs

]]> Cette affirmation est
fausse (donc c'est la
bonne réponse). Les
tests révèlent la
présence de bugs sur
les cas effectivement
testés, mais ils ne
peuvent jamais prouver
l'absence de bugs sur
des entrées non testées.
Edsger Dijkstra a résumé
cela par : « Tester ne
peut prouver l'absence
de bugs ».

]]> Tests et débogage — Q26 : Trois familles d'erreurs On distingue habituellement les
erreurs de syntaxe, les
erreurs d'exécution et les
erreurs sémantiques (ou
logiques). Quelle catégorie est
la plus difficile à détecter
automatiquement ?

]]> Mémorable : « ce qui ne
compile pas, ne s'exécute
pas ; ce qui s'exécute peut
planter ; ce qui ne plante
pas peut quand même être
faux ». Les tests servent
surtout à détecter la
troisième catégorie.

]]> 1.0 0.0 0 true true abc Les erreurs de syntaxe, car elles cassent toute l'exécution

]]> Erreur : ces erreurs sont au
contraire les plus
faciles à détecter. Python
refuse de lancer le programme
et affiche immédiatement
SyntaxError, avec le
numéro de ligne. Aucune
mystère.

]]> Les erreurs d'exécution, car le programme s'arrête en cours de route

]]> Erreur : ces erreurs sont
aussi facilement repérables.
Le programme s'arrête en
levant une exception, avec
une trace d'erreur précise
(IndexError,
ZeroDivisionError, etc.).
On voit immédiatement où
chercher.

]]> Les erreurs sémantiques, car le programme s'exécute sans planter, mais ne fait pas ce qu'il devrait faire

]]> Bonne réponse : c'est le bug
le plus pernicieux. Aucun
message d'erreur, juste un
résultat faux. Seuls des
tests bien choisis ou une
relecture attentive
permettent de le détecter.
Exemple : une boucle qui
commence à l'indice 1 au
lieu de 0.

]]> Les trois catégories sont équivalentes

]]> Erreur : ces trois
catégories diffèrent
radicalement par leur mode
de détection. La syntaxe est
détectée par l'analyseur
syntaxique, l'exécution par
l'interpréteur, la sémantique
uniquement par les tests ou
la relecture humaine.

]]> Tests et débogage — Q27 : Plusieurs cas dans un test Comment écrire un test qui
vérifie le comportement d'une
fonction carre sur plusieurs
entrées sans dupliquer le code
?

]]> Schéma général d'un test
paramétré : une liste de
couples (entrée, sortie
attendue), parcourus dans
une boucle qui vérifie
chaque cas. La bibliothèque
pytest formalise cela avec
le décorateur
@pytest.mark.parametrize.

]]> 1.0 0.0 0 true true abc `python
def test_carre():
return carre(0) and carre(1) and carre(3)
`

]]> Erreur : ce code ne vérifie
pas que les valeurs
renvoyées sont
correctes. Il vérifie
seulement qu'aucune n'est
fausse au sens booléen.
Comme carre(0) == 0,
l'expression renvoie 0
(faux) sans que cela
signale un bug.

]]> `python
def test_carre():
assert carre(0) == 0
assert carre(1) == 1
assert carre(3) == 9
assert carre(-2) == 4
`

]]> Cette version fonctionne
aussi, mais l'énoncé
demandait précisément
d'éviter la duplication. De
plus, ici, dès qu'un
assert échoue, les
suivants ne sont pas
exécutés et l'on ignore
quels autres cas posent
problème.

]]> `python
def test_carre():
for x, attendu in [(0, 0), (1, 1), (3, 9), (-2, 4)]:
assert carre(x) == attendu, f"échec pour x = {x}"
`

]]> Bonne réponse : on parcourt
une liste de couples
(entrée, sortie attendue),
on vérifie chaque cas avec
assert. Le message après
la virgule indique
précisément quel cas a
échoué, ce qui facilite le
débogage. C'est aussi le
principe des tests
paramétrés de pytest.

]]> `python
def test_carre():
assert carre == 9
`

]]> Erreur : on compare la
fonction elle-même (un
objet) à 9, ce qui est
toujours faux. Il faut
appeler la fonction avec
des paramètres et comparer
son résultat.

]]>