Reprendre l'un des projets proposés aux chapitres 1 à 10 et rédiger sa…

Prenons la piste de projet du chapitre 10 : « une page qui réagit », ici un convertisseur de bases reprenant le chapitre 1.

Noyau minimal. L'utilisateur saisit un entier positif en décimal et le programme affiche son écriture en binaire et en hexadécimal.

Ce qui n'en fait pas partie. Pas de conversion en sens inverse, pas de nombres négatifs, pas de flottants, pas d'interface graphique.

Modules et prototypes.

Jeu de tests, écrit avant le code :

def test_nominaux():
    assert vers_base(45, 2) == "101101"
    assert vers_base(45, 16) == "2D"
    assert vers_base(255, 16) == "FF"

def test_limites():
    assert vers_base(0, 2) == "0"      # le cas que la boucle oublie
    assert vers_base(1, 2) == "1"
    assert vers_base(16, 16) == "10"   # premier report de chiffre

def test_aller_retour():
    """Propriete : convertir puis revenir redonne le nombre."""
    for n in range(0, 300):
        for b in (2, 8, 16):
            assert depuis_base(vers_base(n, b), b) == n

Planning en cinq étapes.

Ce que le jeu de tests apporte ici, et qu'on n'aurait pas trouvé seul : le troisième test est d'une autre nature que les deux premiers. Il ne vérifie pas des valeurs choisies à la main, mais une propriété — aller et revenir redonne le point de départ — sur $900$ cas d'un coup. C'est le genre de test qui prend deux lignes et attrape ce que vingt assertions écrites à la main laissent passer.

Le piège de l'étape 3 : vers_base(0, 2). Une boucle « tant que $n>0$ » ne s'exécute pas et renvoie la chaîne vide. Le cas est dans les tests parce qu'on s'est demandé quelles étaient les limites, pas parce qu'on l'a rencontré.