Quel est le moyen le plus convaincant d’exiger des tests unitaires formalisés?

https://stackoverflow.com/questions/120460

02-07-2019
|

Question

Cela présuppose certainement que les tests unitaires sont une bonne chose. Nos projets comportent un certain nombre de tests unitaires, mais ils sont au mieux incohérents.

Quels sont les moyens les plus convaincants que vous avez utilisés ou que vous avez utilisés avec vous pour convaincre tout le monde que les tests unitaires formalisés sont une bonne chose et qu'il est vraiment dans l'intérêt de ces projets "volumineux" . Je ne suis pas un développeur, mais je suis en assurance qualité et je voudrais améliorer la qualité du travail fourni pour qu'il soit prêt à être testé.

Par tests unitaires formalisés, je parle simplement de

Identification des tests unitaires à écrire
Identifier les données de test (ou les décrire)
Écriture de ces tests
Suivi de ces tests (et réutilisation si nécessaire)
Rendre les résultats disponibles

La solution 13

Donc, deux ans après avoir posé cette question, j’ai trouvé qu’une réponse inattendue était qu’il était nécessaire de passer à un nouveau SDLC. Il y a cinq ans, nous avons établi notre premier SDLC officiel. Cela a amélioré notre situation, mais a laissé de côté certaines choses importantes, telles que l'automatisation. Nous sommes en train de mettre en place un nouveau SDLC (sous une nouvelle direction) dont l'un des locataires est l'automatisation. Pas simplement des tests unitaires automatisés, mais des tests fonctionnels automatisés.

Je pense que la leçon à retenir est que je pensais trop petit. Si vous envisagez de modifier la façon dont vous créez un logiciel, optez pour un «jeu complet» et faites un changement radical plutôt que de proposer un changement progressif si vous n'êtes pas habitué à cela.

Autres conseils

Une méthode très convaincante consiste à effectuer des tests unitaires formalisés, quelle que soit l'activité de votre équipe / société. Cela peut demander un effort supplémentaire de votre part, surtout si vous n'êtes pas expérimenté dans ce type de pratique.

Lorsque vous pourrez alors montrer que votre code est meilleur et que vous êtes plus productif que vos collègues développeurs, ils vont vouloir savoir pourquoi. Puis alimentez-les avec vos méthodes de tests unitaires préférées.

Une fois que vous avez convaincu vos collègues développeurs, convainquez la direction ensemble.

J'utilise Maven avec Surefire et Cobertura plugins pour toutes mes versions. Les scénarios de test réels sont créés avec JUnit , DbUnit et EasyMock .

Identification des tests unitaires J'essaie de suivre Test Driven Development mais, pour être honnête, je ne fais généralement que cela pour une poignée de cas de test, puis je reviens et crée des tests pour les cas Edge et des cas d'exception plus tard.

Identification des données de test DbUnit est idéal pour charger des données de test pour vos tests unitaires.

Rédaction de scénarios de test J'utilise JUnit pour créer les cas de test. J'essaie d'écrire des scénarios de test auto-documentés, mais j'utiliserai Javadocs pour commenter quelque chose qui n'est pas évident.

Suivi & amp; Rendre les résultats disponibles J'intègre les tests unitaires dans mon cycle de construction Maven à l'aide du plug-in Surefire et j'utilise le plug-in Corbertura pour mesurer la couverture obtenue par ces tests. Je génère et publie toujours un site Web, y compris les rapports Surefire et Cobertura, dans le cadre de ma construction quotidienne afin de pouvoir voir quels tests ont échoué / réussi.

L’événement qui m’a convaincu est que nous avons réussi à faire régresser un bogue trois fois, en trois versions consécutives. Une fois que j’ai réalisé à quel point j’étais plus productif en tant que programmeur quand je ne corrigeais pas constamment les erreurs triviales une fois qu’ils étaient passés chez le client, et que je pouvais avoir un sentiment flou de chaud que le code des collègues ferait ce qu’ils prétendaient, un converti.

À l’époque où j’ai fait du développement Cobol sur des ordinateurs centraux, nous l’avons fait religieusement dans les différentes sociétés où j’ai travaillé et c’est accepté comme une façon de faire parce que l’environnement l’imposait. Je pense que c’était un schéma très typique de l’époque et que certaines des raisons pourraient vous être applicables: -

Comme dans la plupart des environnements mainframe, nous avions trois domaines: développement, assurance qualité et production. Les programmeurs développés en développement et en unité ont testé là-bas, et une fois qu'ils ont signé et ont été satisfaits, l'unité a été migrée vers l'environnement d'assurance qualité (avec les documents de test et de résultats), où elle a été testée par une équipe dédiée d'assurance qualité. Le développement de la migration de l'assurance qualité était une étape formelle qui s'est déroulée du jour au lendemain. Une fois le contrôle qualité effectué, le code a été migré vers la production - et nous avons eu très peu de bogues.

La motivation pour que les tests unitaires soient terminés et corrects était que si vous ne le faisiez pas et qu'un bug était trouvé par le personnel du service d'assurance qualité, il était évident que vous n'aviez pas fait le travail. Par conséquent, votre réputation dépend de votre rigueur. Bien sûr, la plupart des gens se retrouvaient avec un bug occasionnel, mais les codeurs qui produisaient du code solide et testé tout le temps avaient rapidement la réputation d'une star et ceux qui produisaient du code buggy étaient aussi remarqués. La poussée serait toujours d'augmenter votre jeu, et par conséquent la culture produite en était une qui a poussé vers le code sans bug livré la première fois.

Extraction de points pertinents -

La réputation du codeur est liée à la livraison d'un code testé exempt de bogues
Le temps système associé au déplacement du code testé par l'unité au niveau supérieur, incite donc à ne pas le répéter et à le faire correctement du premier coup.
Tests du système effectués par différentes personnes pour les tests unitaires - idéalement une équipe différente.

Je suis sûr que votre environnement sera différent, mais les principes peuvent être traduits.

Parfois, l’exemple est la meilleure solution. Je trouve également que rappeler aux gens que certaines choses ne se produisent tout simplement pas lorsque les choses sont sous test. La prochaine fois que quelqu'un vous demandera d'écrire quelque chose, faites-le avec des tests, peu importe. Vos pairs finiront par être jaloux de la facilité avec laquelle vous pouvez modifier votre code et savent que cela fonctionne toujours.

En ce qui concerne la gestion, vous devez souligner le temps perdu en raison de l’explosion nucléaire qui se produit lorsque vous devez modifier la base de code X qui n’est pas testée.

De nombreux développeurs ne réalisent pas à quel point ils refacturent sans s’assurer de préserver le comportement sur l’ensemble du système. Pour moi, c’est le plus grand avantage pour les tests unitaires et le TDD, à mon avis.

Modification de la configuration logicielle requise
Modifications logicielles adaptées aux besoins

La seule certitude est le changement. La modification de code non testé nécessite que le développeur connaisse tous les effets secondaires comportementaux possibles. La réalité est que les codeurs qui pensent pouvoir lire toutes les permutations le font en procédant par tâtonnement d'essais et d'erreurs jusqu'à ce que rien ne se casse à l'évidence. À ce stade, ils s'enregistrent.

Le programmeur pragmatique reconnaît qu'il / elle n'est pas parfait et qu'il sait tout, et que les tests sont comme un filet de sécurité qui leur permet de marcher rapidement et en toute sécurité sur la corde raide du refactoring.

Pour ce qui est de savoir quand écrire un test sur un code vierge, il faudrait que je défende le plus possible. Passez du temps à définir les comportements que vous souhaitez extraire de votre système et écrivez des tests pour exprimer ces constructions de niveau supérieur. Les tests unitaires peuvent venir alors que les pensées se cristallisent.

J'espère que cela vous aidera.

Éducation et / ou certification.

Donnez aux membres de votre équipe une formation formelle dans le domaine des tests, éventuellement avec un examen de certification (en fonction des membres de votre équipe et de votre propre attitude à l’égard de la certification). Vous pousserez les tests à un niveau supérieur de cette façon et les membres de votre équipe seront plus susceptibles d'adopter une attitude professionnelle à l'égard des tests.

Il existe une grande différence entre convaincant et nécessitant .

Si vous trouvez un moyen de convaincre vos collègues de les écrire, c'est parfait. Cependant, si vous créez des règles formalisées et que vous leur demandez d'écrire des tests unitaires, ils trouveront un moyen de surmonter ce problème. En conséquence, vous obtiendrez un ensemble de tests unitaires qui ne valent rien: il y aura un test unitaire pour chaque classe disponible et ils testeront les setters et les getters.

Réfléchissez à deux fois avant de créer et d'appliquer des règles. Les développeurs savent bien les surmonter.

Pour la première fois, il vous suffit de les écrire et de leur montrer que cela en vaut la peine. J'ai trouvé sur trois projets que c'est le seul moyen de convaincre les gens. Certaines personnes qui ne codent pas (par exemple, les chefs de projet débutants) ne seront pas en mesure de voir la valeur tant que cela ne les regardera pas de face.

Dans mon équipe logicielle, nous avons tendance à rédiger une petite analyse de rentabilisation sur ces problèmes et à les présenter à la direction afin de disposer du temps nécessaire pour créer et suivre les tests. Nous expliquons que le temps nécessaire pour tester est bien compensé lorsque le moment crucial est venu et que tout est prévu. Nous avons également mis en place un serveur de construction Hudson pour centraliser le suivi des tests unitaires. Les développeurs ont ainsi plus de facilité à se tenir au courant des échecs des tests et à découvrir les problèmes récurrents.

Rappelez à votre équipe ou aux autres développeurs qu’ils sont des professionnels et non des amateurs. Travaillé pour moi!

De plus, c’est une norme de l’industrie de nos jours. Sans expérience des tests unitaires, ils sont moins souhaitables et moins utiles en tant qu'employés pour de futurs employeurs potentiels.

En tant que chef d'équipe, il est de ma responsabilité de m'assurer que mes programmeurs effectuent des tests unitaires sur tous les modules sur lesquels ils travaillent. Je suppose qu’à ce stade, il n’est même pas question de savoir comment les convaincre, c’est nécessaire. Pas parfois, pas sur des projets de grande envergure, tout le temps. Les tests unitaires constituent la première ligne de défense contre la mise en production de quelque chose que vous devrez entretenir. Si quelque chose est mis en production qui n'a pas été complètement testé par l'unité et le système, alors il reviendra vous mordre. Je suppose que l’une des politiques que nous avons ici pour soutenir ceci est que s’il survient en production ou pose des problèmes, alors le programmeur responsable du codage et du test de ce module sera celui qui devra s’occuper des problèmes, effectuera le nettoyage. , etc. Cela seul est un assez bon facteur de motivation.
L'autre est qu'il s'agit d'orgueil. Je travaille dans un magasin d'environ 75 codeurs. Bien que ce soit un gros problème, il est vraiment suffisamment petit pour que nous puissions tous nous connaître. Il est également suffisamment petit pour que nous sachions sur quoi l’autre travaille, et lorsqu’il passe à la production, nous sommes conscients de toute défaillance, défaillance, etc. Si vous êtes prudent, testez les unités et le système, les chances de déplacer quelque chose à la production sans provoquer d'échecs augmente de manière significative. Cela peut prendre un certain temps avant de passer à la production et de ne pas le réaliser, mais il y a de gros avantages à ne pas déconner. C'est vraiment agréable d'entendre des félicitations dans le couloir lorsque vous déplacez un projet et que cela ne gâche rien.

Écrivez-en plusieurs et montrez que les tests unitaires ont amélioré votre productivité et la qualité de votre code. Sans preuve, les gens ne croient parfois pas que cela en vaut la peine.

Vous pourriez vous inspirer d'une initiative de Google. Leur équipe de test a commencé à mettre en place des exemples, des conseils et des avantages à l’intérieur des toilettes afin de mieux faire connaître les avantages de l’automatisation des tests.

https://testing.googleblog.com/2007 /01/introducing-testing-on-toilet.html

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow