en résumé du code qui permet de tester du code. On écrit du code qui va executer la fonction en lui passant des parametres et en comparant le résultat avec celui attendu par lé développeur ex: si on a une fonction qui fait une somme ainsi
function somme(a, b){
return a + b;
}
on pourrait la tester en faisant
test('verifier que 3 plus 4 egal 7', function(){
var ajout = somme(3, 4);
verifierEgal(ajout, 7);
});
on lance le test, et on vérifie ainsi la conformité, en faisant ça pour chaque petit bout de notre puzzle, on n'a plus qu'à lancer notre suite de tests (l'ensemble de nos tests) pour vérifier la conformité de la totalité de notre tableau ! en l'exécutant on aura soit dans le terminal ou le navigateur, soit des petit symbole verts en cas de réussite ou des croix rouge pointant vers la fonction fautive qu'il suffit maintenant de corriger puis relancer les tests.
ce qui nous amène à deux approches de ces outils :
On écrit une première version de notre programme sans se soucier de sa qualité, après on écrit notre suite de tests. On réécrit (autrement dit on refactorise) ensuite au fur et à mesure notre programme en ayant la garantie qu'on n'introduira pas de nouveaux bug dans nos différentes pièces du puzzle. On dit souvent dans le développement qu'il ne faut plus toucher un programme qui fonctionne, les test-unitaires permettent de mitiger ce mythe.
C'est l'approche inverse, on écrit d'abord nos test unitaires, nos tests sont donc au rouge, et on écrit notre code au fur et à mesure pour faire passer au vert. C'est une approche plus difficile à mettre en oeuvre au début, mais qui force à mieux préparer son plan d'attaque et plus de rigueur sans quoi ça peut vite devenir infernal. En terme de gestion de temps, c'est très efficace.