$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 Un type particulier de variable

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

]]> Une vérification automatique du comportement attendu

]]> 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 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.

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

]]> 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.

]]> 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 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 une valeur booléenne

]]> 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 vérifiées lors
d'une exécution ordinaire du programme, pas seulement pendant une
phase de mise au point.

]]> Si la condition est fausse, elle lève une AssertionError

]]> 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.

]]> Tests et débogage — Q03 : Ce que vérifie un test de fonction Élise écrit des assertions qui appellent uniquement sa fonction
moyenne, sur quelques listes choisies à l'avance. Que vérifient
ces tests ?

]]> Tester chaque fonction séparément, sur des cas bien choisis (liste
d'un seul élément, valeurs égales, etc.), permet de localiser
rapidement un bug. Ces tests ne prouvent pas la correction : ils
augmentent la confiance.

]]> 1.0 0.0 0 true true abc Le comportement de moyenne seule, sur les cas choisis

]]> Bonne réponse : tester une fonction isolément permet de savoir
précisément laquelle se comporte mal quand un test échoue. Les
tests restent limités aux cas choisis.

]]> Que moyenne est correcte pour toutes les listes possibles

]]> Erreur : un jeu de tests ne vérifie que les cas écrits. Son succès
ne garantit pas que la fonction est correcte pour toutes les
listes.

]]> La vitesse d'exécution de la fonction moyenne

]]> Erreur : une assertion compare des valeurs, elle ne mesure aucune
durée. Ces tests portent sur les résultats renvoyés.

]]> Le fonctionnement du programme entier qui utilise moyenne

]]> Erreur : ces assertions n'appellent que moyenne. Le reste du
programme n'est pas exécuté, il faudrait d'autres tests pour le
vérifier.

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

]]> L'instruction assert est rapide à écrire et lisible. On peut
ajouter après la condition un message affiché en cas d'échec :
assert carre(3) == 9, "carre(3) devrait valoir 9".

]]> 1.0 0.0 0 true true abc test carre(3) == 9

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

]]> 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.

]]> 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.

]]> carre(3)

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

]]> 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 Les paramètres de configuration 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, qui indique le fichier et la ligne

]]> 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é.

]]> 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.

]]> 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.

]]> 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.

]]> À ralentir intentionnellement le programme

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

]]> À afficher la valeur d'une variable à un moment précis

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

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

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

]]> 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 fonctionnalité que l'utilisateur final 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.

]]> Un type particulier de mémoire

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

]]> Un comportement non conforme aux spécifications

]]> 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 nouvelle version d'un logiciel

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

]]> 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 Des entrées prévues avec leur sortie attendue

]]> 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 complet d'utilisation du programme et de ses options

]]> 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.

]]> Un test choisi au hasard

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

]]> 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 Aucun problème n'est signalé

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

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

]]> 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.

]]> On accède à liste[5], un indice qui n'existe pas

]]> 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.

]]> 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 Réduire l'entrée au cas le plus simple qui reproduit 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.

]]> 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.

]]> 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 — 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 La syntaxe de range est incorrecte avec deux arguments

]]> Erreur : range(1, n) est valide (début
inclus, fin exclue). Le code s'exécute
sans erreur, le bug est purement logique.

]]> Aucun bug, la fonction additionne bien tous les éléments

]]> Erreur : pour [1, 2, 3], la fonction
renvoie 5 et non 6. Le premier élément
n'est jamais ajouté.

]]> La fonction ne renvoie jamais la moindre valeur utile

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

]]> Le premier élément, liste[0], n'est jamais ajouté

]]> Bonne réponse : la boucle commence à
l'indice 1 au lieu de 0. 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 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.

]]> 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.

]]> La dernière ligne (en bas), avec le type d'erreur

]]> 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.

]]> Quelque part au milieu de la trace d'erreur affichée

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

]]> 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 Le reproduire avec une entrée minimale fiable

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

]]> 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.

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

]]> Un débogueur permet d'arrêter le programme sur une ligne choisie,
de l'exécuter ensuite instruction par instruction et d'observer à
chaque étape la valeur des variables, sans modifier le code.

]]> 1.0 0.0 0 true true abc Un antivirus qui détecte les programmes malveillants

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

]]> Un compilateur qui traduit le code source en exécutable

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

]]> Un outil qui exécute pas à pas et montre les variables

]]> Bonne réponse : on avance ligne par ligne et on inspecte l'état du
programme. Les environnements de programmation en proposent
souvent un, très utile pour comprendre un bug.

]]> Un fichier de journalisation des erreurs du programme

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

]]> Tests et débogage — Q17 : Une assertion en tête de fonction `python
def moyenne(notes):
assert len(notes) > 0
total = 0
for n in notes:
total = total + n
return total / len(notes)
`
Quel est le rôle de l'assertion placée au début de la fonction ?

]]> Une précondition décrit ce que la fonction attend de ses arguments ;
une postcondition décrit ce qu'elle garantit sur son résultat. Une
assertion placée en tête de fonction vérifie la précondition à
chaque appel.

]]> 1.0 0.0 0 true true abc Vérifier une postcondition sur la valeur renvoyée

]]> Erreur : une postcondition porte sur le résultat, après le calcul.
Cette assertion est vérifiée au début, sur l'argument notes,
avant que la moyenne soit calculée.

]]> Faire renvoyer 0 à la fonction quand la liste est vide

]]> Erreur : une assertion ne renvoie aucune valeur. Si la condition
est fausse, elle arrête le programme avec une AssertionError.

]]> Afficher un avertissement puis poursuivre le calcul

]]> Erreur : une assertion n'affiche rien quand la condition est
vraie, et arrête le programme quand elle est fausse. Le calcul ne
se poursuit pas.

]]> Vérifier une précondition : la liste reçue n'est pas vide

]]> Bonne réponse : l'assertion porte sur l'argument, avant tout
calcul. Si on appelle moyenne([]), le programme s'arrête avec
une AssertionError au lieu d'effectuer une division par zéro.

]]> Tests et débogage — Q18 : Garder le test qui a révélé un bug Nour a corrigé sa fonction remise, dont le bug avait été révélé
par l'assertion assert remise(100) == 90. Que faire de cette
assertion maintenant que le test passe ?

]]> Un jeu de tests s'enrichit au fil de la mise au point : chaque bug
corrigé laisse derrière lui un test qui l'aurait détecté. La qualité
et le nombre des tests comptent autant que leur succès.

]]> 1.0 0.0 0 true true abc La remplacer par print(remise(100))

]]> Erreur : un affichage ne vérifie rien automatiquement. Il faudrait
relire la valeur à chaque exécution pour repérer une erreur.

]]> La réécrire avec la valeur que renvoie la fonction aujourd'hui

]]> Erreur : un test compare le résultat à la valeur attendue d'après
la spécification, pas à ce que renvoie le code actuel. Sinon il
passerait même si la fonction était fausse.

]]> La supprimer, puisque le bug est corrigé

]]> Erreur : une modification ultérieure du code pourrait réintroduire
le bug. Sans ce test, rien ne permettrait de s'en apercevoir.

]]> La garder dans le jeu de tests

]]> Bonne réponse : ce cas a déjà mis un bug en évidence. Le conserver
permet de détecter immédiatement le retour de ce bug après une
future modification.

]]> Tests et débogage — Q20 : Écrire les tests avant le code Quel est l'avantage principal de la démarche qui consiste à écrire
les tests avant le code ?

]]> Écrire d'abord les tests oblige à fixer les résultats attendus, y
compris sur les cas limites comme une liste vide : c'est une
spécification précise que le code devra respecter. Le succès des
tests ne garantit pas pour autant la correction du programme.

]]> 1.0 0.0 0 true true abc 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.

]]> Elle dispense totalement d'avoir à écrire des commentaires

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

]]> 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 force à clarifier la spécification avant de coder

]]> 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.

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

]]> Causes fréquentes d'un bug intermittent : une valeur tirée au
hasard avec le module random, une saisie de l'utilisateur, le
contenu d'un fichier lu. Une fois le cas fautif retrouvé, on
l'ajoute au jeu de tests.

]]> 1.0 0.0 0 true true abc Ignorer le bug

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

]]> Relancer le programme jusqu'à ce que le bug ne se produise plus

]]> Erreur : si le bug ne se
manifeste pas lors d'une
exécution donnée, il n'a pas
disparu pour autant. Sans
diagnostic de la cause, il
finira par resurgir.

]]> Relever les données de chaque exécution pour le reproduire

]]> Un bug qui ne se produit que parfois dépend souvent d'une donnée
qui change d'une exécution à l'autre, comme un tirage au hasard ou
une saisie. En notant ces données, on retrouve le cas qui déclenche
le bug et on peut le reproduire.

]]> Ralentir l'exécution avec des appels à time.sleep()

]]> Erreur : ralentir le programme ne change pas les données qu'il
traite. Si le bug dépend d'une valeur tirée au hasard ou saisie, il
reste présent et resurgira.

]]> 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, isoler, corriger, puis ajouter un test

]]> 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 fonction chercher n'existe peut-être pas encore

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

]]> La syntaxe de assert est invalide sans message d'erreur

]]> Erreur : le message après la virgule est
facultatif, assert expression seul est
valide. Le défaut est sémantique : le test
n'est pas assez précis.

]]> Aucun problème, le test vérifie que 2 est trouvé à l'indice 1

]]> Erreur : le test ne compare jamais la
valeur renvoyée à 1. Il passe pour tout
résultat « vrai », par exemple 2 ou True.

]]> Il vérifie seulement que le résultat est « vrai »

]]> Bonne réponse : ce test est trop laxiste.
Tout résultat vrai au sens booléen (1, 2,
True...) le fait passer, indice faux
compris. 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 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.

]]> Le débogage permet d'éviter complètement 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 tests trouvent les bugs, le débogage les corrige

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

]]> 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.

]]> 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 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.

]]> 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 ».

]]> 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.

]]> 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.

]]> 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 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, le programme tourne mais est faux

]]> 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 d'erreurs 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.

]]> 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.

]]> 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 : une liste de couples (entrée, sortie attendue),
parcourue dans une boucle qui vérifie chaque cas avec assert.
Ajouter un cas ne demande qu'un couple de plus dans la liste.

]]> 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 elle répète la
même logique de test à
chaque ligne, ce que
l'énoncé demandait
précisément d'éviter. La
version paramétrée factorise
ce schéma et indique, en cas
d'échec, la valeur fautive.

]]> `python
def test_carre():
for x, attendu in [(0, 0), (1, 1), (3, 9), (-2, 4)]:
assert carre(x), attendu
`

]]> Erreur : la virgule n'est pas une
comparaison. assert carre(x), attendu
vérifie seulement que carre(x) est vrai
et utilise attendu comme message
d'échec : le test échoue pour x = 0 (car 0
est faux) et ne compare jamais la valeur
renvoyée à la valeur attendue.

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

]]> Bonne réponse : on parcourt une liste de couples
(entrée, sortie attendue) et 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.

]]> Tests et débogage — Q28 : Tester un résultat flottant Le test assert moyenne([0.1, 0.2]) == 0.15 échoue alors que la
fonction semble correcte. Comment écrire ce test correctement ?

]]> Comparer des flottants demande une tolérance : abs(a - b) < eps
est le schéma à retenir.

]]> 1.0 0.0 0 true true abc assert round(moyenne([0.1, 0.2])) == 0.15

]]> Erreur : round sans précision arrondit à l'entier, le test
échouerait toujours.

]]> assert abs(moyenne([0.1, 0.2]) - 0.15) < 1e-9

]]> Bonne réponse : les flottants ne sont pas exacts ; on vérifie
que l'écart avec la valeur attendue est négligeable.

]]> En supprimant ce test, les flottants ne se testant pas

]]> Erreur : les calculs flottants se testent, avec une tolérance.

]]> assert moyenne([0.1, 0.2]) == 0.15000000000000002

]]> Erreur : recopier la valeur affichée rend le test fragile et
incompréhensible.

]]> Tests et débogage — Q29 : Regrouper les tests d'une fonction Pourquoi écrire les assertions qui testent moyenne dans une
fonction test_moyenne() plutôt qu'en vrac dans le programme ?

]]> Des tests regroupés et nommés forment une batterie réutilisable :
un appel, un verdict.

]]> 1.0 0.0 0 true true abc Pour que les tests s'exécutent plus vite, en bloc

]]> Erreur : la vitesse est la même ; c'est l'organisation qui
change.

]]> Parce que assert n'est autorisé que dans une fonction

]]> Erreur : assert s'écrit n'importe où.

]]> Pour cacher les tests aux utilisateurs du programme

]]> Erreur : les tests ne sont pas secrets, ils documentent même
l'usage attendu.

]]> Pour relancer tous les tests d'un seul appel

]]> Bonne réponse : la fonction de test se rappelle après chaque
changement de code, ce qui détecte aussitôt une régression.

]]> Tests et débogage — Q30 : Une fonction difficile à tester La fonction calcul(a, b) affiche le résultat avec print au lieu
de le renvoyer. Pourquoi est-elle difficile à tester avec assert ?

]]> Séparer le calcul de l'affichage est une règle de conception :
les fonctions qui renvoient se testent, celles qui affichent non.

]]> 1.0 0.0 0 true true abc Parce qu'elle ne renvoie rien à comparer, l'affichage n'étant pas une valeur

]]> Bonne réponse : assert calcul(2, 3) == 5 compare None à
5. Renvoyer le résultat, et l'afficher ailleurs, rend la
fonction testable.

]]> Parce qu'une fonction avec print ne peut pas être appelée dans un test

]]> Erreur : elle peut être appelée, mais son résultat n'est pas
récupérable.

]]> Parce que print est plus lent qu'un return

]]> Erreur : la vitesse n'est pas en cause.

]]> Parce que les tests n'acceptent que des fonctions à un paramètre

]]> Erreur : le nombre de paramètres n'a aucune importance.

]]> Tests et débogage — Q31 : Combien de tests écrire La spécification de tarif(age) distingue trois cas : moins de
12 ans, de 12 à 17 ans, 18 ans et plus. Combien de tests
écrire au minimum ?

]]> Le jeu de tests se déduit de la spécification : chaque cas, chaque
frontière.

]]> 1.0 0.0 0 true true abc Un seul, avec une valeur quelconque

]]> Erreur : un seul test laisse deux cas sans vérification.

]]> Cent, pour être sûr de couvrir tous les âges

]]> Erreur : le nombre ne fait pas la qualité ; ce sont les cas
couverts qui comptent.

]]> Au moins un par cas, plus un à chaque frontière

]]> Bonne réponse : trois cas appellent trois tests, et les valeurs
12 et 18 méritent chacune un test supplémentaire.

]]> Aucun, la spécification suffisant à garantir le code

]]> Erreur : la spécification dit ce qui doit se passer ; les tests
vérifient que le code le fait.

]]> Tests et débogage — Q32 : Des tests qui dépendent les uns des autres Le test test_retrait ne réussit que s'il est lancé après
test_depot, qui alimente le compte. Quel est le problème ?

]]> Chaque test construit son contexte, exécute une opération, vérifie
le résultat : indépendant, il reste lisible quand il échoue.

]]> 1.0 0.0 0 true true abc Aucun, l'ordre des tests étant toujours le même

]]> Erreur : l'ordre peut changer, et un test qui dépend d'un autre
cache une mauvaise conception.

]]> Les tests ne sont pas indépendants

]]> Bonne réponse : un test doit pouvoir être lancé seul, dans
n'importe quel ordre. Sinon un échec devient impossible à
interpréter.

]]> test_depot devrait être supprimé

]]> Erreur : les deux tests sont utiles ; c'est leur dépendance qui
pose problème.

]]> Les deux tests devraient être fusionnés en un seul

]]> Erreur : fusionner masque quelle opération échoue.

]]> Tests et débogage — Q33 : Un test qui ne teste rien Que vaut le test assert double(4) == double(4) ?

]]> La valeur attendue d'un test vient de la spécification, jamais du
code testé.

]]> 1.0 0.0 0 true true abc Il vérifie que double(4) vaut 8

]]> Erreur : le nombre 8 n'apparaît nulle part.

]]> Il vérifie que double est déterministe

]]> Erreur : même si c'était l'intention, cela ne vérifie pas la
spécification de double.

]]> Rien, il réussit quel que soit le résultat de double

]]> Bonne réponse : comparer la fonction à elle-même ne dit pas si
elle renvoie 8. Un test compare le résultat à une valeur
attendue, écrite à la main.

]]> Il échoue toujours, une fonction ne pouvant être comparée à elle-même

]]> Erreur : deux appels identiques donnent la même valeur, le test
passe.

]]> Tests et débogage — Q34 : Un indice hors de la liste Que signifie le message IndexError: list index out of range ?

]]> Chaque type d'erreur nomme sa cause : IndexError pour un indice,
KeyError pour une clé, NameError pour un nom inconnu.

]]> 1.0 0.0 0 true true abc Un indice inexistant dans la liste a été utilisé

]]> Bonne réponse : avec une liste de cinq éléments, t[5]
provoque cette erreur ; le dernier indice valide est 4.

]]> La liste contient un élément du mauvais type

]]> Erreur : le type des éléments donnerait une TypeError.

]]> La liste est trop longue pour la mémoire disponible

]]> Erreur : la taille de la liste n'est pas en cause.

]]> La liste n'a pas été définie avant son utilisation

]]> Erreur : une liste non définie donnerait une NameError.

]]> Tests et débogage — Q35 : Une concaténation refusée Le message TypeError: can only concatenate str (not "int") to str
apparaît. Quelle instruction peut l'avoir provoqué ?

]]> Le message indique les deux types en conflit : c'est lui qui
désigne la conversion à ajouter.

]]> 1.0 0.0 0 true true abc 12 + 3

]]> Erreur : deux entiers s'additionnent.

]]> int("12")

]]> Erreur : cette conversion est valide.

]]> "Total : " + "12"

]]> Erreur : deux chaînes se concatènent sans problème.

]]> "Total : " + 12

]]> Bonne réponse : + entre une chaîne et un entier est refusé.
Il faut str(12) ou une virgule dans print.

]]> Tests et débogage — Q36 : Réduire le cas qui échoue La fonction trier donne un résultat faux sur une liste de deux
mille éléments. Quelle est la première chose à faire ?

]]> Réduire l'exemple est la première étape du débogage : plus le cas
est petit, plus la cause est visible.

]]> 1.0 0.0 0 true true abc Chercher la plus petite liste qui reproduit l'erreur

]]> Bonne réponse : une liste de trois ou quatre éléments qui échoue
se trace à la main et révèle le mécanisme du bug.

]]> Relancer le programme jusqu'à ce que le résultat soit bon

]]> Erreur : un bug déterministe se reproduit à chaque fois.

]]> Ajouter des éléments à la liste pour voir si l'erreur persiste

]]> Erreur : agrandir le cas le rend encore plus difficile à
analyser.

]]> Réécrire la fonction entièrement

]]> Erreur : sans comprendre l'erreur, on risque de la réécrire.

]]> Tests et débogage — Q37 : Une modification à la fois Pour corriger un bug, Théo change trois lignes d'un coup, et le
résultat devient juste. Pourquoi cette méthode est-elle risquée ?

]]> Le débogage est une expérience scientifique : une hypothèse, une
modification, une vérification.

]]> 1.0 0.0 0 true true abc Python n'accepte qu'une modification par exécution

]]> Erreur : rien de tel n'existe.

]]> Trois modifications prennent trop de temps à écrire

]]> Erreur : le temps d'écriture n'est pas le problème.

]]> Il ignore laquelle a corrigé le bug, et si les autres en créent un

]]> Bonne réponse : modifier une seule chose, tester, puis
continuer permet d'attribuer chaque effet à sa cause.

]]> Le résultat juste prouve que les trois lignes étaient fausses

]]> Erreur : une seule ligne fautive suffit à expliquer le bug.

]]> Tests et débogage — Q38 : Une erreur signalée à la mauvaise ligne Python signale une SyntaxError à la ligne 12, qui semble
pourtant correcte. Que vérifier ?

]]> Quand la ligne signalée paraît juste, remonter d'une ligne : une
parenthèse, un crochet ou des guillemets non fermés en sont presque
toujours la cause.

]]> 1.0 0.0 0 true true abc La ligne 13, Python se trompant toujours d'une ligne

]]> Erreur : Python ne se trompe pas ; il signale où la lecture
échoue.

]]> La version de Python, qui change la numérotation des lignes

]]> Erreur : les numéros de ligne sont fiables ; c'est la cause qui
est en amont.

]]> La ligne précédente, une parenthèse non fermée y étant fréquente

]]> Bonne réponse : une parenthèse ouverte à la ligne 11 fait lire
la ligne 12 comme la suite de l'expression, et l'erreur n'est
détectée que là.

]]> Rien, une SyntaxError disparaissant au second lancement

]]> Erreur : une erreur de syntaxe est stable tant que le code n'est
pas corrigé.

]]> Tests et débogage — Q39 : Avant ou pendant l'exécution Quelle différence entre une SyntaxError et une ZeroDivisionError ?

]]> Erreurs de syntaxe au chargement, erreurs d'exécution en cours de
route, erreurs de logique sans message : trois familles, trois
façons de les chercher.

]]> 1.0 0.0 0 true true abc Aucune, ce sont deux noms pour la même erreur d'exécution

]]> Erreur : elles ont des causes et des moments très différents.

]]> La première est détectée avant l'exécution, la seconde pendant

]]> Bonne réponse : une faute de syntaxe empêche le programme de
démarrer ; une division par zéro n'apparaît que lorsque
l'instruction fautive est atteinte.

]]> La première vient de Python, la seconde du système d'exploitation

]]> Erreur : les deux sont signalées par Python.

]]> La première est grave, la seconde sans conséquence sur le résultat

]]> Erreur : les deux arrêtent le programme.

]]>