Développeurs seniors et tests unitaires - obligatoire ?Sont-ils autorisés à utiliser des laquais ?[fermé]

StackOverflow https://stackoverflow.com/questions/23688

  •  09-06-2019
  •  | 
  •  

Question

Les développeurs seniors devraient-ils être exemptés des tests unitaires - ou devraient-ils être autorisés à utiliser des laquais pour les mettre en œuvre ?Quelle est la meilleure façon de motiver les personnes qui ne sont pas habituées à utiliser les techniques de tests unitaires à les adopter ?

Était-ce utile?

La solution

Je dirais que d'un point de vue puriste du TDD (c'est-à-direcelui qui pense que les tests unitaires devraient être écrits avant mise en œuvre), les développeurs seniors devraient écrire plus tests unitaires que des laquais, pas moins.

La raison en est que, puisque les tests unitaires passent en premier, leur écriture nécessite une connaissance approfondie de la base de code.Si vous laissez les laquais les écrire, vous laissez essentiellement ceux qui connaissent le moins votre domaine dicter la structure de votre base de code.Cela me semble une mauvaise idée.

Autres conseils

Je pense que demander à des laquais de faire des tests unitaires pour quelqu'un d'autre détruit l'intérêt d'avoir des tests unitaires pour commencer.Le programmeur qui écrit du code doit savoir comment le code doit être interrompu et quel est son comportement attendu.Ce n’est pas parce que quelqu’un d’autre le fait que le programmeur d’origine est libéré de cette responsabilité.

(Formulation maladroite en raison de la neutralité de genre.)

La personne qui écrit le test = définit le fonctionnement du système = le « patron »

Les personnes qui mettent en œuvre les tests sont ce qu'on appelle des « laquais ».

On dirait le cas d'un vieux chien qui n'aime pas les nouveaux tours.Et comme on dit, c'est difficile de les faire changer...TFD (test-first development) est très amusant une fois que vous commencez à le faire, organisez peut-être un atelier interne d'une journée sur TDD ou TFD impliquant toute l'équipe.

Les développeurs seniors devraient-ils être exemptés des tests unitaires

Absolument pas.Ils ne devraient donc pas du tout être des développeurs seniors.Les développeurs seniors devraient être des leaders qui montrent la voie, l'idée que des laquais le font semble absurde - pourquoi s'embêter à tester alors.

Je pense qu'une façon possible de gérer ces situations serait que le développeur senior puisse écrire la majorité des tests unitaires.Cela signifie qu'ils définissent et conçoivent la manière dont le programme devrait travail.Les laquais peuvent ensuite écrire le code correspondant au test, apprenant ainsi les philosophies de conception du senior pendant qu'ils y sont.

Première partie (Développeurs seniors et tests unitaires)

Quand je pense au TDD ou Test Driven Design, les tests unitaires ont pour objectif de chasser les conception évolutive du système, en espérant garantir une amélioration continue.
L'écriture du test façonne le code ou met en évidence les problèmes liés à une décision déjà prise, ce qui, espérons-le, aboutira à un processus de refactorisation pour augmenter la qualité de la conception.

D'après mon expérience, le développeur senior est normalement la personne ayant le plus d'expérience et de capacités, ce qui signifie qu'il devrait être mieux placé pour repérer ces opportunités de refactoring.(Détecter les odeurs du code)

Il y a trois situations auxquelles je peux penser, de mémoire, où quelqu'un d'autre rédige les tests à votre place. pourrait être acceptable.

  1. Tests d'acceptation/Tests clients/Tests de bout en bout.Appelez-les comme vous voulez, mais je veux dire les tests qui commencent au point de saisie des données (service Web, page Web, saisie sur l'écran de l'application) et traversent toute la pile du système (vers une base de données, appel à un autre service, retour à l'écran des résultats de saisie, etc.).Cela pourrait être écrit par quelqu'un qui n'implémente pas les détails des unités individuelles qui seront exercées par les tests.
  2. Programmation jumelée (Modèle de ping-pong) -

    A écrit un nouveau test et voit qu'il échoue.
    B implémente le code nécessaire pour passer le test.
    B écrit le prochain test.
    A le met en œuvre.

  3. Tests de correction de bugs - Lorsqu'un bug est détecté, il est souvent recommandé d'écrire un test qui échoue et qui expose le défaut.Une fois ce test en place, il est tout à fait possible que quelqu'un implémente le code qui fait passer le test.Je ne pense pas que ce soit une très bonne idée, car le fait d'écrire le test qui échoue en raison du défaut donne souvent une idée de la façon dont un correctif pourrait être produit.

En bref, ma réponse à votre première question serait la suivante : non, un développeur senior ne devrait pas être dispensé d'écrire des tests unitaires.

Partie II (Motiver les gens à passer des tests)

C'est quelque chose avec lequel j'ai eu des problèmes dans le passé.Même si j'essaie désormais d'effectuer du TDD aussi souvent que nécessaire, il m'a fallu quelques mois pour comprendre qu'il y avait un réel avantage à rédiger des tests.
Je pense qu'il est assez difficile d'essayer de montrer aux autres les avantages du TDD et des tests unitaires.Ce n'est que lorsque la personne expérimente par elle-même ce moment « ah ha » où les tests TDD/Unitaires ont mis en évidence une subtilité dans son code, qu'elle aurait autrement pu manquer, ou l'ont aidé à corriger un bug en peu de temps, qu'elle voir les avantages.Les amener à ce point peut être assez difficile.
Personnellement, je suis arrivé là-bas grâce à la programmation en binôme dans le modèle Ping Pong susmentionné, en travaillant avec un TDDer expérimenté et en voyant le code que nous écrivions pour résoudre une fonctionnalité non triviale évoluer vers ce que l'on pourrait appeler une solution élégante.Suivi par ce travail qui passe par le contrôle qualité et dans l'environnement en direct sans aucun défaut signalé.

En bref, je pense que faire équipe avec un programmeur expérimenté et déjà convaincu des avantages de l'écriture de tests unitaires est un excellent moyen d'aider quelqu'un à se motiver pour écrire des tests unitaires.

Absolument pas;du moins parce qu'il est beaucoup plus facile d'écrire des tests pour le code que vous développez vous-même.Mais il est important pour tous les développeurs, quelle que soit leur ancienneté, de tester unitairement tout leur code ;s’ils se développent en sachant que leur code doit être testable, les fruits de leur travail seront bien plus importants.

Si vous avez besoin de motiver les développeurs à effectuer des tests unitaires, insistez simplement sur les avantages et le temps qui sera économisé à long terme.S'ils prennent l'habitude d'écrire des tests unitaires pour leur code, ils commenceront bientôt à le faire automatiquement.

Si un développeur senior n'effectue pas ses propres tests, alors il n'est pas un développeur senior.

Un manque de volonté de tester est presque toujours un signe de paresse ou d’ineptie (ou les deux), et ce n’est pas non plus un trait que l’on devrait trouver chez un développeur senior.

Le seul scénario auquel je puisse penser dans lequel il serait approprié pour un développeur senior de demander à quelqu'un d'autre d'écrire ses tests unitaires serait dans le cas où une nouvelle recrue junior est mise au courant des choses.Cela pourrait être une bonne tâche pour se mouiller les pieds tout en écrivant du code.

L'un des plus grands avantages des tests unitaires réside dans le retour immédiat qui vous indique vos performances.Si vous externalisez la mise en œuvre de vos tests, vous n’obtiendrez aucun retour si votre conception fonctionne ou non.Et les personnes aux prises avec une mauvaise conception n’ont aucun moyen de la corriger.

Si vous êtes un développeur senior, c'est en partie parce que vous êtes suffisamment expérimenté pour savoir que les tests unitaires sont une excellente pratique de développement qui aide toi produire de meilleurs logiciels

Je ne souscris pas à la religion du TDD, mais je vois beaucoup de valeur dans les tests unitaires/etc, et je le fais beaucoup pendant que je code.

Le fait est que personne vraiment sait ce que le code est censé faire, sauf la personne qui l'a écrit, et souvent, ils ne le savent même pas non plus.

En gardant cela à l'esprit, vous n'obtiendrez pas beaucoup de valeur du fait que des « laquais » rédigent les tests, car

  1. Ils n’auront pas une compréhension approfondie de tous les cas subtils
  2. Ils ne se soucieront pas du code car ils n’y ont rien investi
  3. Ils auront l’impression d’être traités comme des idiots.

Même s’ils SONT des idiots, personne n’aime être traité comme tel.Si vous souhaitez que vos collaborateurs démissionnent, c'est un bon moyen de les encourager.

Personne ne devrait être dispensé d’écrire des tests unitaires.Tous les développeurs doivent être capables de les écrire, et les tests unitaires doivent également être examinés dans le cadre de votre processus de révision de code.La complexité des tests unitaires dépend généralement des compétences du développeur - le code le plus complexe étant confié à des développeurs plus expérimentés, d'où le nombre plus complexe et plus important de tests unitaires qui leur sont également attribués.

Si vous avez un ou plusieurs développeurs qui ne sont pas capables de s'adapter, vous devriez essayer de leur donner une assistance individuelle et jumeler les tests unitaires aux développeurs jusqu'à ce qu'ils commencent à comprendre.Il n’y a rien de suffisamment complexe techniquement pour qu’une personne capable d’écrire du code ne soit pas en mesure de produire des tests unitaires.Si cela semble être le cas, c'est probablement le signe avant-coureur d'un problème plus vaste lié aux compétences de cette personne.

Personnellement, je pense qu'il est également utile que les testeurs soient capables au moins de comprendre les tests unitaires qui font partie du projet.La collaboration entre les développeurs et les testeurs est très importante pour diagnostiquer et corriger correctement les défauts.Je ne m'attendrais pas à ce qu'ils aient à les écrire, mais ils devraient pouvoir s'asseoir avec un développeur et examiner le concept du pourquoi/comment un test échoue ou non.

Eh bien, je dirais oui, mais seulement si le laquais est autorisé à laisser la correction des bugs trouvés au senior.Cela lui apprendra.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top