Êtes-vous un étudiant de l'EPFL à la recherche d'un projet de semestre?
Travaillez avec nous sur des projets en science des données et en visualisation, et déployez votre projet sous forme d'application sur Graph Search.
Concept
Test driven development
Résumé
Test-Driven Development (TDD), ou développement piloté par les tests en français, est une méthode de développement de logiciel qui consiste à concevoir un logiciel par des itérations successives très courtes (ou petits pas), telles que chaque itération est accomplie en formulant un sous-problème à résoudre sous forme d'un test avant d'écrire le code source correspondant, et où le code est continuellement remanié dans une volonté de simplification.
À l'origine, il s'agissait simplement d'écrire les tests avant de coder, et cette méthode s'appelait le Test-First Design. Puis elle évolua vers une granularité de développement plus fine : pour une ligne de test en échec, une ligne de code de production est écrite, afin que le test réussisse. Afin d'entériner cette granularité de ligne à ligne entre code de test et code de production, trois lois ont émergé.
Ces lois connaissent différentes variantes très similaires entre 2005 et 2008 (2005, 2006, 2007 et 2008), toujours écrites par Robert C. Martin : elles sont ici énoncées selon les termes utilisés en 2008. Or l'emploi de l'expression "test unitaire" dans ces lois prête ici largement à confusion. Par test unitaire, ces lois ne désignent pas un cas de test complet, mais en fait une unique assertion de test. Le cas de test complet devrait être obtenu après avoir répété plusieurs fois les étapes correspondant à ces trois lois, sachant que la résolution d'une erreur de compilation constitue déjà une itération à part entière. En 2014, Robert C. Martin reformule d'ailleurs les lois de TDD, et le terme « unitaire » disparaît.
Une formulation exacte et exempte de toute ambiguïté de ces 3 lois serait plutôt comme suit. La forme est volontairement affirmative ici, car l'esprit humain comprend plus aisément ce qu'il faut faire que ce qu'il ne faut pas faire.
On fait ainsi la distinction entre l'assertion à l'origine de l'échec du test et le test qui échoue lors de son exécution. De plus, on ne présume pas de la forme de test la plus adéquate, ni ne se restreint à une seule possible, ce qui est d'autant plus pragmatique.
Source officielle
À propos de ce résultat
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.