Meilleures pratiques de tests unitaires pour un débutant de tests unitaires

Ces dernières années, je n'ai écrit que de petits composants pour des personnes dans des projets plus importants ou de petits outils. Je n'ai jamais écrit de test unitaire et il me semble toujours qu'apprendre à les écrire et en faire un prend beaucoup plus de temps que de simplement lancer le programme et de tester pour de vrai.

Je suis sur le point de démarrer un projet à assez grande échelle qui pourrait prendre quelques mois et, même si j'essaierai de tester des éléments au fur et à mesure que je les écris (comme toujours), je me demande si les tests unitaires pourraient me faire gagner du temps.

Je me demandais simplement si quelqu'un pouvait donner de bons conseils:

1. Dois-je envisager des tests unitaires au début du projet et éventuellement adopter une approche TDD.
2. Dois-je simplement écrire des tests au fur et à mesure, une fois chaque section terminée.
3. Dois-je terminer le projet, puis écrire des tests unitaires à la fin.

Certains diront le contraire, mais je vous suggère de séparer les tests TDD et unitaires. TDD est tout à fait un changement mental et les tests unitaires semblent initialement prendre du temps. Si vous les considérez comme un élément, il y a un risque que vous ne voyiez pas suffisamment d'avantages immédiatement et il y aura une tentation de simplement abandonner TDD et les tests unitaires avec.

La première chose est d'écrire des tests unitaires. Ils n'ont pas besoin d'être parfaits au début. Apprenez simplement à tester de petites unités de code et à utiliser la simulation pour isoler les composants.

C'est le plus gros preneur de temps mais il a de loin le plus gros gain. Une fois que vous remarquerez que vous n'avez plus à parcourir 14 pages Web pour accéder à celle que vous souhaitez tester, vous saurez de quoi je parle.

Pour moi, le grand moment d'Eureka était une application Windows où j'essayais de tester une expression rationnelle qui exigeait que je remplisse deux formulaires avant de pouvoir y accéder. J'ai installé NUnit et écrit un test autour de cette méthode et j'ai vu à quelle vitesse j'ai économisé des heures de test. Ensuite, j'ai ajouté plus de tests pour traiter les cas marginaux. Etc.

Apprenez ensuite à bien rédiger les tests unitaires. Apprenez l'équilibre entre les tests fragiles qui sont rapides à écrire et à écrire de nombreux tests individuels. C'est assez simple. La leçon est qu'idéalement, chaque test ne teste qu'une chose, mais vous apprenez rapidement combien de temps cela prend, alors vous commencez à vous pencher un peu sur la règle jusqu'à ce que vous écriviez un test qui rompt à chaque changement de code, puis vous revenez vers le bon équilibre (qui est plus proche de la première que de la seconde).

TDD est, comme je l'ai dit, un changement mental majeur dans votre façon de travailler. Cependant, cela n'ajoutera pas beaucoup de temps à votre processus de développement une fois que vous écrivez déjà des tests. Et vous pourrez, je le promets, voir votre style de codage s'améliorer sous vos yeux. Ou plutôt, si vous ne le laissez pas tomber, ce n'est pas pour vous.

Une dernière chose à garder à l'esprit est que le TDD ne se limite pas aux tests unitaires. La conception pilotée par les tests d'acceptation fait partie intégrante de TDD. Une autre bonne raison de ne pas les mélanger dans votre esprit.

Je suis d'accord avec les autres (n'écrivez certainement pas vos tests à la fin, le TDD prend du temps pour apprendre, commencez par les tests comme vous le pouvez, visez le TDD complet éventuellement). Mais je voulais ajouter une chose en réponse à votre commentaire: "Je me demande si les tests unitaires pourraient me faire gagner du temps."

Ma réponse est un oui sans équivoque. J'ai appris l'approche TDD il y a environ 10 ans, après un temps similaire de codage sans tests. Ces jours-ci, si je fais quelque chose de court (<250 loc) et simple, ou quelque chose de jetable, alors je ne vais pas le TDD. Sinon, je le fais, et précisément parce que cela fait gagner du temps.

Le gain de temps se présente de trois manières: moins de WTF, moins de débogage et moins de peur. La première est évidente: vous passez beaucoup moins de temps à vous demander ce que fait la chose que vous avez construite. Lorsque vous rencontrez un problème, le débogage est beaucoup plus facile, car a) vous détectez instantanément les bogues testés et b) les bogues non testés ont moins d'endroits à cacher.

La chose la moins peur, cependant, c'est plus subtile. Tant que vous n'avez pas passé un certain temps dans une base de code TDD, vous ne réalisez même pas combien de temps vous passez à vous soucier des changements que vous apportez. X fonctionne-t-il? Va-t-il casser Y? Y a-t-il du Z qui pourrait être affecté? Avec TDD, cela disparaît, car vous transformez vos peurs en tests, puis l'ordinateur automatise l'inquiétude. Un développeur courageux est un développeur plus rapide.

1. Dois-je regarder l'unité au début et adopter une approche TDD.

2. Dois-je simplement écrire des tests au fur et à mesure que chaque section est terminée.

L'un ou l'autre, mais pas la troisième option .

Comme l'a noté @pdr, l'apprentissage des tests unitaires appropriés prend du temps. Vous voulez certainement prendre votre temps pour apprendre au début du cycle de vie du projet, pas vers la fin lorsque la date limite se profile à votre tête. De cette façon, vous êtes déjà à jour et pouvez même commencer à en récolter les bénéfices au moment où l'échéance se rapproche, car vous avez détecté la plupart des bogues plus tôt dans le cycle de vie du projet.

Notez que le tout premier test unitaire est toujours le plus difficile, surtout si vous testez du code déjà écrit. Un tel code peut ne pas être adapté aux tests unitaires, vous pouvez donc avoir du mal à câbler tous les objets avec l'état approprié pour le test. Choisissez donc un test de bas niveau facile et assez isolé pour vos premières tentatives de tests unitaires, puis progressivement vous pouvez augmenter le niveau de défi. Une fois que le premier appareil de test est prêt, le prochain cas de test est beaucoup plus facile, et au moment où vous arrivez au quatrième, vous produirez des cas de test comme sur un tapis roulant. C'est à ce moment que vous commencez à ressentir la bonté de pouvoir prouver de manière répétée et démontrable que votre code fonctionne ...

Personnellement, je préfère l'approche TDD et je ne pense pas que ce soit si difficile - cela prend de la persévérance, mais je crois que plus tôt vous commencez avec TDD, plus tôt vous commencez à voir les avantages des tests unitaires dans l'ensemble. Cependant, il se peut que les premiers tests unitaires soient mieux écrits pour le code que vous avez déjà. Ensuite, une fois que vous avez compris, vous pouvez commencer à expérimenter avec TDD.

Je pense que la meilleure chose à faire pour un débutant est de s'attaquer à certains katas de code qui se prêtent aux tests unitaires. Par exemple; valider une adresse e-mail. TDD devient le flux naturel une fois que vous avez abordé quelques-uns de ces codes Katas. Consultez le code kata suivant pour le validateur d'adresse e-mail que j'ai mentionné: E-mail Validator

Pour une explication de ce que sont les Katas Code pour ceux d'entre vous qui ne connaissent pas, consultez le lien suivant: Katas Code