Que devrais-je faire lorsque qu'un collègue rejette mes commits parce qu'ils contiennent des tests unitaires ?

Question

J'ai déménagé d'une équipe à une autre au sein de la même entreprise. Dans mon ancienne équipe (c++ hardcore) nous faisions beaucoup de tests unitaires. Dans ma nouvelle équipe (également c++), ils font plutôt des tests fonctionnels. Lors de la revue, ils rejettent mon code à cause des tests unitaires. La plupart de l'équipe est intéressée à apprendre quelque chose de nouveau mais pas le gars important qui a une approche de développeur héritée. Il doit accepter le code avant le commit. Il résiste au changement. Des conseils ?

// mise à jour : Je vous informerai dans ce sujet de ce qui s'est passé avec ma quête mais s'il vous plaît comprenez que c'est une grande entreprise, cela prend du temps. Juste pour clarifier, les tests que je fais sont bons et ont toujours fonctionné dans d'autres équipes. Je ne suis pas nouveau dans ce domaine. De temps en temps, je dois casser des dépendances car le code est franchement mauvais. En c++, il faut parfois le faire. Cela peut introduire des changements dans le code de prod juste à cause des tests. Je crois que le fait d'avoir des tests unitaires justifie ce genre de changements simples. C'est mieux de les avoir que de ne pas les avoir.

// mise à jour 2 : Merci pour tous ces bons conseils, clairement il n'y a pas de solution miracle ici :( La plupart de l'équipe est convaincue mais 2 développeurs seniors (15 ans et +) s'y opposent toujours. Je ferai une courte présentation à ce sujet et le reste de mon équipe me soutiendra, j'espère que ces gars-là finiront par être d'accord :) Pour me détendre un peu, j'ai commencé à apprendre le ruby :)

Answer 1

Vous venez de rencontrer le problème logiciel le plus difficile de tous : les gens. Bien que j'hésite à remettre en question votre patron sans plus de contexte (par exemple, est-ce vraiment la photo complète des tests ?), un rejet total de votre code simplement parce que vous avez inclus des tests unitaires est une pratique discutable au mieux.

La route la plus judicieuse est d'avoir une discussion en tête-à-tête avec cette personne afin de comprendre sa position. Vous décrivez votre patron comme étant réticent au changement, mais généralement les gens ne sont pas si tranchés. Par exemple, peut-être considère-t-il le volume de code que vous soumettez comme risqué étant donné votre nouveau statut sur le projet, sans comprendre que vos tests unitaires vous permettent d'écrire plus de code parce que vous pouvez avoir plus confiance en celui-ci. Donc, je lui laisserais le bénéfice du doute, et j'aurais d'abord une conversation sincère avec lui.

Voici quelques questions à poser lors de votre conversation :

• Quels sont vos avis sur les tests unitaires ? Comment s'intègrent-ils dans notre stratégie de test globale ?

• Quels sont vos problèmes avec les tests unitaires que j'ai soumis ? Sont-ils insuffisants ou manquent-ils de quelque façon ? Êtes-vous okay avec les tests unitaires eux-mêmes, mais préféreriez-vous que mon code soit organisé différemment ?

• Pourquoi tous nos codes devraient-ils être testés au niveau fonctionnel ?

• Tous les tests unitaires sont-ils mauvais ou inappropriés pour notre projet?

• Comment comptez-vous découvrir les problèmes liés aux entrées spécifiques des méthodes lorsque ces conditions sont plus complexes à reproduire à des niveaux d'interface plus élevés ?

• Si vous avez une objection spécifique aux tests unitaires étant validés, y a-t-il vraiment une objection à utiliser les tests unitaires localement pour que je puisse au moins vérifier mon propre code ?

Si vous sentez que vous comprenez maintenant sa position et qu'elle est intenable avec la façon dont vous voulez écrire des logiciels, vous avez une autre question à vous poser : Aimez-vous suffisamment le travail pour rester dans l'équipe malgré les pratiques professionnellement discutables, ou est-il temps de commencer à chercher ailleurs ?

À l'inverse, si vous pensez maintenant comprendre pourquoi la règle est là et que vous pensez qu'elle est judicieuse à la lumière du contexte global du projet, alors hourra ! Vous avez évité une crise potentielle en agissant de manière professionnelle, vous pouvez rester avec votre nouvelle équipe, et vous pouvez retourner à la partie amusante : le développement de logiciels.

---

Éditer : Je ne peux vraiment pas être d'accord avec certains des messages dans cette question disant à l'OP de s'adapter à l'équipe. La normalisation des pratiques n'est bonne que lorsque l'équipe adhère à la pratique. Au lieu de dire à l'OP de serrer les dents et de se conformer, nous devrions l'encourager à comprendre pourquoi la règle est en place, afin qu'il puisse évaluer si elle a du sens en fonction de ses propres mérites.

Le manager a également des explications à fournir pour aider l'OP à voir les choses de son point de vue. Bien sûr, tout le monde ne sera pas d'accord avec les managers tout le temps. J'ai dirigé des projets ou des équipes, et j'ai pris mes propres décisions qui ne pouvaient pas plaire à tout le monde, mais j'ai toujours essayé de les prendre avec les contributions de tout le monde d'abord, afin de pouvoir arriver à la meilleure décision. À mon avis, imposer un ensemble de "normes" par décret managérial sans tenir compte de l'impact sur l'équipe et en ignorant les suggestions alternatives fait de vous un mauvais manager, pas un bon.

Answer 2

Stocker les tests unitaires dans une version de contrôle parallèle et ne soumettre que le code au système central. Il passera en revue votre code sans tests unitaires et vous pourrez toujours en bénéficier...

De plus, je suggère d'utiliser l'un des contrôles de version distribués, vous pourrez jouer avec un nouveau jouet amusant, et lorsque l'un de vos autres collègues voudra essayer, il pourra facilement adopter et étendre votre suite de tests.

Éditer Pour clarifier les commentaires suivants:

Je suggère qu'il mette en place un dépôt local de code source pour ses tests unitaires. Le code lui-même serait toujours synchronisé avec le dépôt géré (par le biais du processus de soumission normal, mais sans soumettre les tests avec le code).

Il pourrait également conserver les tests unitaires qu'il juge utiles sur son disque dur et cela ne changerait rien, de la même manière que tout développeur que je connais a quelques fichiers "outils" autour pour diverses fins.

L'idée est qu'en travaillant avec des tests unitaires, il peut espérer que son taux de bogues soit inférieur à celui des autres. Cela peut aider à argumenter à ce sujet avec son chef technique. Tant qu'il termine le travail assigné à temps, je ne vois pas pourquoi il ne pourrait pas travailler comme il le souhaite.

Answer 3

La chose la plus importante dans une équipe de développement est de respecter les normes, même si vous n'êtes pas d'accord avec elles. Si tout le monde fait sa propre chose, alors il est inutile d'avoir des normes.

Vous pourriez conserver les tests unitaires pour votre propre satisfaction/confiance personnelle. Peut-être qu'un jour vous pourrez démontrer que votre approche a empêché un bug de réapparaître ou a bénéficié à l'équipe de quelque manière, et alors il sera plus facile de faire passer votre point de vue.

Un jour, vous serez celui qui établit les normes et certaines personnes seront en désaccord avec vous. Vous pourrez alors leur raconter cette histoire.

Avertissement : J'utilise des tests unitaires lorsque c'est approprié et toute personne travaillant pour moi sera encouragée à en faire de même.

Answer 4

Les tests unitaires ont des coûts, pas seulement des avantages. De http://www.joelonsoftware.com/items/2009/09/23.html:

Zawinski n'a pas fait beaucoup de tests unitaires. Ils "paraissent excellents en principe. Avec un rythme de développement tranquille, c'est certainement la voie à suivre. Mais quand vous devez passer de zéro au terminé en six semaines', eh bien, je ne peux pas le faire à moins que je ne coupe quelque chose de ma liste. Et ce que je vais éliminer, ce sont les choses qui ne sont pas absolument cruciales. Et les tests unitaires ne sont pas cruciaux. Si il n'y a pas de test unitaire, le client ne va pas se plaindre de cela."

De: http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html

Mon principal problème pour le moment avec les tests unitaires est que quand je change une conception, j'obtiens un tas de tests qui échouent. Cela signifie que je vais soit écrire moins de tests, soit faire moins de grands changements de conception. Les deux sont de mauvaises choses.

Answer 5

Dans quelques minutes, vous devriez recevoir quelques réponses, principalement favorables pour vous. Montrez ce fil de discussion à la personne qui résiste au code. :)