S’il y a bien quelque chose de chronophage et de littéralement barbant, c’est bien le debug de sa solution.. Qui n’a jamais connu les interminables sessions de correction à droite, puis à gauche, puis re à droite, etc..
Tout simplement, chaque nouvelle ligne de code peut porter préjudice à la solution actuelle (avoir du beau code découplé et modulaire limite toutefois la casse) et entrainer des régressions deci delà. La solution? Pour chaque bloc de code (fonction, module) écrit dans votre projet, écrivez un ou plusieurs tests (unitaires et/ou fonctionnels) associés. A chaque fois.
Ça peut vous paraître chiant, vous sembler prendre du temps et être contre productif au début, mais je vous garanti que cela va vous économiser un temps précieux plus votre projet avancera. Chaque nouvelle ligne qui entraine une régression vous sera signalée instantanément, plus de mauvaise surprise en production. Tout bug trouvé se voit corrigé et consigné dans un test pour ne plus jamais le voir ressurgir: ça vous donne envie de débugger car désormais le débug à un sens et n’est plus un processus vain et non pérenne!
Et vous, mettez-vous des tests dans vos développements, unitaires, fonctionnels? Je cherche à mettre en place des tests javascript (car de plus en plus du coeur de ma solution est uniquement en js désormais), avez-vous des reco à ce sujet? Merci d’avance pour vos commentaires :)
Il y a quelques mois, je t’aurai conseillé [Jasmine](http://pivotal.github.com/jasmine/) mais aujourd’hui, je te conseillerai plutôt [Mocha](http://visionmedia.github.com/mocha/).
Have fun :)
J’avais déjà jetée un oeil à Jasmine, mais Mocha a l’ai top en effet! Merci :)
La qualité est un métier donc ca prend autant de temps que le reste. Un logiciel, et pas forcement de la faute du developpeur, contiendra toujours des bugs.
Merci pour cet article
Je pense que la décision de mettre en place des TU est une décision importante.
En avoir est effectivement une sécurité pour la maintenabilité du projet. Et cela force les dev de se poser les bonnes questions !!
Et ne pas en mettre au début équivaut à n’en mettre jamais je pense :)
Par contre il faut garder en tête les points suivants :
_ avoir des TU c’est entre +50% et +100% de temps de dev
_ faire de bons TU n’est pas inné. En général on a tendance a être trop “gentil” avec son propre code. Et les cas limites sont parfois dur à imaginer. C’est pour cela qu’en TDD on code d’abord le test avant le code, histoire de pas avoir d’apriori sur son code
_ avoir des TU n’empêche pas de faire des tests d’intégration
Tout dépend de la taille du projet, de l’équipe, de la criticité des bugs ( genre si tu es une banque ou un blog c’est pas pareil ) ….
Merci pour ce commentaire! :)
* 50% à 100% de temps de dev en plus? Wouaou, ils sont costaud tes tests, je pense que chez Balloon on s’approche de 20%-30% max pour faire nos tests (il s’agit dans notre cas plus de tests fonctionnels qu’unitaires)
* Faire des bons tests: en effet, il faut y réfléchir et avoir une bonne vision de la feature développée. Après, il y a le coverage il me semble qui permet de passer au crible les lignes/fonctions/méthodes n’étant pas prises en compte dans les tests
* tout à fait d’accord :)
Imagine que tu fais 3 ou 4 tests par méthode d’un webservice je pense que tu arrives facilement à +50% :)
Après c’est sur que tout dépend ou tu mets la balance j’avoue :)
Je trouve que le compromis suggéré par Pierre Chapuis est aussi une solution à envisager : écrire des tests unitaires après avoir trouvé un bug ( pour la non-régression ) . Ca peut-être un choix stratégique intéressant.
En effet, je fais un peu des deux:
Nous faisons majoritairement des tests fonctionnels (du genre, j’ente mes identifiants sur le signin, s’ils sont bon on doit arriver ici. S’ils sont faux, ici. Etc etc..) mais sans aller trop loin dans la complexité (d’où 20 à 30% de temps de plus pour les tests)
Mais en effet, la killer feature c’est de consigner un bug dans un test de non-régression. C’est ce qui in fine nous fait gagner le plus de temps.
Il faut juste trouver la bonne balance entre en faire pas mal au début et consigner moins de bugs, ou l’inverse ;)
Je vais être honnête : j’écris en général peu, voire quasiment pas de tests unitaires.
Par contre :
* Je reprends des bonnes pratiques du Design by Contract quand j’écris des choses complexes : validation des entrées, des sorties, voire des invariants de boucle. Pour du Web je me contente des entrées.
* J’écris des tests d’intégration à très haut niveau (équivalents à l’utilisation de Selenium ou Mechanize pour du Web).
* J’écris des tests unitaires de non-régression quand je corrige un bug.
* Pour des programmes critiques, complexes et pour lesquels il n’est pas évident de voir s’ils fonctionnent ou pas, je les implémente deux fois de manière différente et j’écris des scripts pour comparer leur comportement.
Après tout dépend des programmes, il y a des exceptions. Par exemple mon implémentation de MessagePack a une suite de tests relativement complète parce que 1) les tests sont relativement simples à écrire et 2) c’est assez simple de se tromper dans ce genre de code.
D’ailleurs ça me fait penser qu’un collègue est tombé sur cette réponse à une question sur Quora hier, qui correspond assez à ce que je fais (sauf “Avoid macros if you can”) : http://www.quora.com/What-methodology-should-one-adopt-in-order-to-code-a-bug-free-C-Program/answer/Robert-Johnson
Bonjour.
D’accord avec à peu près tout ce qui a été dit. Je voudrais juste rajouter une précision, quand on parle de “temps en plus pour coder des tests”, il ne faut pas oublier que c’est du temps gagné sur le moyen et long terme puisque cela permet de debugger/corriger des bugs plus vite, et permettre un refactoring très rapide. Au final, ce n’est pas juste du temps en plus ajouté “parce que ca fait bien de faire des tests”.
Salut :)
Je voudrais juste ajouter 2-3 trucs sur les tests. Le premier, c’est qu’un test unitaire permet aussi de documenter la fonction testée; ça montre un cas d’utilisation de ce code, avec un contexte.
Quand on a une bonne couverture de tests, ça permet de ne pas avoir peur du faire du refactoring.
Souvent, aussi, ça permet aussi de développer plus vite : au lieu de lancer l’appli, de me logguer, de passer 2-3 écrans pour tester ma fonctionnalité, j’ai juste à lancer mon test unitaire à l’intérieur de mon IDE (les tests bien faits ne doivent pas mettre trop de temps à s’exécuter).
Et autre point important, ça démystifie la mise en production du code, car on est déjà rassuré par notre couverture de code; et donc du coup, on livre plus souvent (la mise en production devient un non-évènement).
Enfin, comme tout ce qui a déjà été dit, faut juste trouver le juste milieu…