Les assertions c'est bien, et ce n'est pas mutuellement exclusif avec les tests unitaires. Mais ça ne les remplace pas. Dès que tu as un algorithme non trivial (un algorithme quoi! ), tu as plusieurs chemins possibles : les combinaisons se multiplient et les assertions sont inutiles (ou deviennent 3 fois plus nombreuses que les lignes de code 'normales', et vont pourrir ton code).
Si tu fais un algorithme de tri, tu ne vas pas mettre 15 lignes d'assertions (avec des boucles et tout) pour vérifier que tous tes éléments initiaux sont présents, et qu'ils sont bien classés. C'est beaucoup plus sains et simple de faire une dizaine d'assertions dans tes test unitaires du genre :
assertEqual(sort([]), [])
assertEqual(sort([1]), [1])
assertEqual(sort([1, 2]), [1, 2])
assertEqual(sort([2, 1]), [1, 2])
etc…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Les assertions c'est bien, et ce n'est pas mutuellement exclusif avec les tests unitaires. Mais ça ne les remplace pas. Dès que tu as un algorithme non trivial (un algorithme quoi! ), tu as plusieurs chemins possibles : les combinaisons se multiplient et les assertions sont inutiles (ou deviennent 3 fois plus nombreuses que les lignes de code 'normales', et vont pourrir ton code).
Si tu fais un algorithme de tri, tu ne vas pas mettre 15 lignes d'assertions (avec des boucles et tout) pour vérifier que tous tes éléments initiaux sont présents, et qu'ils sont bien classés. C'est beaucoup plus sains et simple de faire une dizaine d'assertions dans tes test unitaires du genre :
assertEqual(sort([]), [])
assertEqual(sort([1]), [1])
assertEqual(sort([1, 2]), [1, 2])
assertEqual(sort([2, 1]), [1, 2])
etc…