Dad 3.0

Après avoir essayé de démystifier les tests dans le premier billet de cette série, puis après vous avoir donné un aperçu de quoi tester, je vous propose de commencer à organiser votre code de test.

Vous avez vu qu’un premier principe de l’organisation des tests est de séparer le code de test du code fonctionnel. Ensuite, il s’agit de les répartir en différents modules et ces classes de type TestCase. Pour cela, je vais commencer par vous présenter ce concept de test unitaire.

Lire la suite

Mon premier billet sur les tests présente le concept et comment, avec peu d’effort, vous pouvez améliorer ce que vous faites déjà. Mais en conclusion, je vous affirme que ce premier jet de tests n’est pas une bonne pratique. Il y a plusieurs raisons et dans ce billet, je vais aborder la question de quoi tester. En particulier pour le langage Python qui a une manière particulière de gérer la visibilité des attributs.

Notez que le concept présenté ici s’applique à tous les langages.

Lire la suite

Une particularité du langage Python est qu’il ne se limite pas au monde des développeurs. Pour l’écrasante majorité de mes stagiaires, écrire un programme n’est pas leur activité principale mais doit les aider dans leur métier. Inutile de dire que tout ce qui a un rapport à la production de code doit aller à l’essentiel.

Du coup, il y a une partie qui provoque toujours la même réaction de lassitude : les tests. Cette réaction d’intérêt mitigé vient du fait qu’ils ne codent que des scripts à usage limité pour lesquels l’investissement d’une démarche de test n’est pas nécessaire. C’est certainement le cas aussi pour tous ceux qui n’écrivent pas du code à usage professionnel.

Vous vous doutez bien que si j’écris ce billet, c’est que la vision du test n’est pas tout à fait exacte et résulte d’une incompréhension de l’objectif du test dit de développeur. Je vous invite donc à lire le billet suivant afin d’essayer de comprendre ce qu’est un test, car vous en faites déjà… ou presque.

Lire la suite