Bonjour,
Aspect souvent rebutant de la programmation, les tests unitaires n’en restent pas moins primordiaux.
Réalisez-vous vous même vos tests ?
Si oui, à quelle fréquence et avec quels outils ?
(j’ai utilisé Hudson en entreprise) sinon à titre perso si j’en avais besoin je n’essayerais que ces deux la Jenkins et/ou Teamcity de Jetbrains.
1 « J'aime »
Qu’entends tu pas “Réalisez” ? Les écrire ou les jouer ?
Si c’est jouer comme @xmaximin a interprété, j’utilise un CI (opensource : travis, pro : jenkins) qui rejoue les tests unitaires (et non les tests d’integrations ou fonctionnels) à chaque nouveau git push.
De plus pour éviter de casser, sur des grosses features j’essaye de replay les tests avant de git push :) car pour les nouveaux features = nouveaux tests donc il faut bien les jouer une fois quand meme avant le git push
Oui, j’essaie de le faire au fur et à mesure que je code.
Je fais principalement du Python, j’utilise :
- https://docs.python.org/2/library/unittest.html
- https://pypi.python.org/pypi/nose2
- http://webtest.readthedocs.org/en/latest/
- http://selenium-python.readthedocs.org/
- et bien d’autre lib en fonction des besoins
Dans ma dernière boite j’ai utilisé Jenkins avec un soft python/c/c++ qui tournais sur set-top box, on utilisait py.test il me semble (que j’utilise sur mes projets perso python, avec le coverage à titre indicatif). Il me semble que c’était à chaque push. On avait tests “unitaires” pour la stabilité utilisant un soft proprio qui fait de la reconnaissance d’image. Ils étaient pas intégré au Jenkins et était géré par l’équipe de validation qui faisaient aussi les tests de validations donc manuellement. On faisait aussi des tests de stabilités génériques avec une télécommande programmable pour lesquels on a développé des sondes écrites en python avec un front en python/django.
Aspect souvent rebutant de la programmation
Je trouvais ça rebutant quand j’en faisait pas systématiquement. Ecrire tout le code et ensuite faire tous les tests c’est hyper relou. Le coup de “je vais prendre du recul et me re-approprier le code” ça marche pas super. Même avec le coverage, j’oublie des cas. De toute façon, je fais les tests ie. je test dans ma console ou un fichier temporaire tout bidon. Avec le TDD je fais le meme test mais je le met dans un test unitaire et je peux le relancer plus tard.
1 « J'aime »
Développant actuellement en javascript fullstack des applications web orientées single page (node.js pour le back), j’utilise mocha/chaï aussi bien pour le back que pour le front. Cela me permet de mutualiser au mieux le code. En règle générale, j’essaye d’écrire les tests avant le code ce qui je trouve dynamise l’émergence des idées et facilite l’organisation du code en plus de fiabiliser l’application. Les tests, c’est aussi de l’enseignement et du retour direct d’expérience ! Dans le cas d’une techno que l’on découvre, les tests c’est un peu comme un super bac à sable.
Pour python, je suis passé à py.test et c’est très cool.
Pour js, j’approuve mocha, chai Et karma en test runner qui permet de ne pas faire de page html pour les tests front end.
Sinon junit pour java (mais au prochain projet je passe sur spock) et l’outil intégré à visual studio pour c#.