EnglishCommencer

Le développement dirigé par les tests

Le cycle rouge, vert, remaniement : écrire d'abord un test qui échoue, puis le code le plus simple qui le fait passer, puis nettoyer ; petits pas, triangulation, ce que la méthode apporte et ce qu'elle ne garantit pas.

  • 26 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Les étapes
  5. Mises en situation

Quelques cartes du deck

  • Développement dirigé par les tests : de quoi s'agit-il ?

    Voir la réponse

    Méthode où chaque morceau de code de production est précédé d'un test automatisé qui échoue et qui définit ce que le code doit faire.

    Le test vient avant le code : il sert de spécification exécutable et oblige à penser l'interface avant l'implémentation.

  • Voici le seul test écrit pour l'instant. Quel code de production est le plus simple, au sens du TDD, pour le faire passer ?

    ```python
    def test_prix_ttc():
    assert prix_ttc(100) == 120
    `

    • return 120
    • return ht * 1.2
    • return round(ht * 1.2, 2)
    • return ht + ht * 20 / 100
    Voir la réponse

    return 120

    Au vert, on écrit le minimum : une constante suffit. C'est le test suivant (par exemple prix_ttc(50) == 60) qui forcera la généralisation, par triangulation.

  • Le cycle se déroule dans l'ordre : … (un test échoue), … (le code minimal le fait passer), puis … (on nettoie sous la protection des tests).

    Voir la réponse

    Le cycle se déroule dans l'ordre : rouge (un test échoue), vert (le code minimal le fait passer), puis remaniement (on nettoie sous la protection des tests).

    Chaque temps a un seul objectif : prouver, faire marcher, puis améliorer. Les mélanger fait perdre le filet des tests.

  • Rouge : de quoi s'agit-il ?

    Voir la réponse

    Premier temps du cycle : on écrit un test qui échoue, ce qui prouve qu'il peut détecter l'absence du comportement voulu.

    Un test qui n'a jamais échoué ne prouve rien : il pourrait passer quoi qu'on écrive. Il faut le voir échouer, pour la bonne raison.

  • Un tour du cycle de TDD : quelle étape vient après « Écrire un test qui décrit le comportement voulu » ?

    • Écrire le code minimal qui le fait passer
    • Relancer tous les tests et les voir passer
    • Remanier le code et la structure
    • Le lancer et le voir échouer
    Voir la réponse

    Le lancer et le voir échouer

    On voit d'abord le test échouer, pour savoir qu'il détecte quelque chose ; le remaniement ne vient qu'une fois la barre verte, et se termine par une nouvelle exécution.

Réviser ce deck