Je viens de rejoindre une équipe qui travaille dans un mode principal toujours pour les 5 dernières années (Java, projet basé sur Maven). Par conséquent, envisagent de tirer parti des tests de l'unité ont toujours été dans le pipeline, ne matérialisant jamais (jusqu'à présent). Une grande équipe de devises a permis de garantir que la qualité du code est généralement bonne et il n'y a pas de problèmes de code structurels, mais il n'y a qu'une culture d'écriture de tests jnuit. Mais j'ai vu les avantages des tests unitaires, je suis un guerrier isolé qui pousse ici pour adoption d'auto-test.
La mise en page de l'équipe est telle qu'une équipe de test distincte effectue un test manuel de la fonctionnalité avant de relancer le code et une équipe de gestion des modifications est un checkgate pour les approbations de changement et les constructions (aucune intégration continue non plus, jusqu'à présent).
Voici les obstacles: parce que la base de code est énorme et que certains des développeurs originaux ont quitté l'équipe, les tests supplémentaires supplémentaires peuvent être trop petits, trop tard. Ajoutez-y que je serais peut-être le seul à appuyer pour les tests unitaires. Bien que mon manager ait été favorable à l'idée, il ne veut pas que l'équipe de changement soit enlèvement de temps supplémentaire requise pour que les tests fonctionnent.
Je suis d'avis qu'un outil CI autonome peut être utilisé pour commencer, et l'équipe de changement doit modifier leurs scripts pour sauter des tests, au fur et à mesure de leur addition.
Que feriez-vous à ma place?
PS: Je suis au courant d'une question similaire sur Stackoverflow , Mais dans celui-ci, l'objectif est de convaincre les différentes parties prenantes et le meilleur chemin de takel; pas une comparaison technologique.
7 Réponses :
Il conviendrait d'écrire des tests pour tester des fonctionnalités spécifiques que vous travaillez et que vous souhaitez rester stable.
Avec une grande application existante qui n'a pas de couverture de test pour le moment, vous ne voudriez pas vous asseoir et écrire des tests tout en une fois pour obtenir une couverture de test d'unité à 100% et que vous ne le ferez jamais. Vous obtiendrez simplement une fonctionnalité spécifique pour les tests. Je ne pense pas qu'il y ait une telle chose aussi peu ou trop tard; Tests unitaires Pour seulement un peu de peuples de fonctionnalités très importants vaut mieux que rien du tout, et certains tests unitaires sont maintenant meilleurs qu'aucun test d'unité de jamais.
Le problème est que je veux que le reste de l'équipe commence également à écrire des tests, et éventuellement de voir sa valeur. Essayer de trouver le chemin du moindre résistance.
Vous pourriez mener par exemple, commencez par écrire quelques tests, puis, car ils aident à retrouver les régressions, se vanteront du temps qu'il a sauvé. ;)
Les tests unitaires sont avantageux, même dans un ancien projet, par exemple, en établissant des tests d'unités, vous pouvez être sûr que le problème n'est pas dans le code existant, mais dans le nouveau code (même si vous avez un processus QA, les bugs obtiennent toujours à travers l'occasion). En outre, ils empêchent les modifications de l'ancien code d'introduire des différences subtiles de comportement. En outre, les tests unitaires documentent le comportement prévu de l'énorme codeBase.
Maintenant, adopter de gros changements ne sont jamais faciles. La première et la plus simple chose consiste à imposer des tests unitaires de tout nouveau code, de sorte que l'effort et la charge de travail de l'unité testant l'ancienne générale de code ne continuent pas à s'accumuler. Ensuite, la deuxième partie est de prendre l'initiative et de créer des tests unitaires pour l'ancien code. Si vous faites cela, vous devriez pouvoir convaincre d'autres membres de votre équipe d'aider à créer des tests d'unités pour le code existant. Si nécessaire, proposez des incitations amusantes, comme prometteuse une fête de pizza pour l'équipe qui crée le plus grand nombre de tests d'unités pour la base de code existante.
Aussi, rappelez-vous à vos coéquipiers que ce n'est pas quelque chose où ils ont besoin de laisser tomber tout ce qu'ils font ... S'ils ne créent qu'un seul test pour un composant existant chaque jour sur leur autre travail, puis éventuellement vous obtiendra un test d'unité pour tous les composants existants de votre codeBase.
On dirait que vous avez un très bon gérant sur la situation.
Deux choses:
Ne vous attendez pas à pouvoir tester pleinement un projet de 5 ans. En supposant que 5 développeurs travaillant depuis 5 ans, vous êtes dans le voisinage de 50 000 heures de programmeur. En supposant que les tests prennent autant de temps à écrire en tant que code, vous feriez très bien d'obtenir une couverture de 2 à 3% en un an.
SO: Testez le nouveau code et écrivez des tests pour modifications de code plus ancien. Get Time / Prenez le temps de mettre en place CI de quelque sorte. Peu à peu, vous allez accumuler une belle batterie de tests.
Puisque vous n'êtes apparemment pas noyé dans des insectes, commencez lentement, gagnez de l'élan.
«En supposant que les tests prennent autant de temps à écrire sous forme de code» la raison principale que l'équipe jamais écrit du code était à cause de la notion qu'ils préféraient dépenser ce temps à écrire un nouveau code. Et c'est la notion que j'ai besoin de combattre. Je pourrais leur montrer les feuilles de calcul, les statistiques sur la manière dont la rédaction de test sauve réellement l'heure à long terme, mais personne n'est intéressé par la longue course. Toute suggestion Comment convaincre ces Devs de commencer à écrire des tests d'unité maintenant?
Oui, dirigez par l'exemple. Mandater la rédaction des tests peut travailler sur une nouvelle équipe (je l'ai fait et j'ai été remercié plus tard par des personnes qui ont pris l'habitude avec eux avec d'autres équipes), mais sur une équipe existante, vous ne les ferez probablement pas envie de ne pas vouloir testez encore plus. Alors ... Commencez à les écrire vous-même. Concentrez-vous sur des bogues (écrivez le test d'échec, puis corrigez le bogue) et sur le nouveau code, en particulier n'importe quel code délicat. La première fois que votre suite attrape un bug de régression sera le moment où vous commencez à faire des convertis.
@Varun - Le meilleur moyen d'obtenir un test de test infecté est d'avoir un test unitaire sauver leur cul à quelques reprises. La seule façon qui peut arriver est d'écrire des tests: P beaucoup de développeurs inconnus avec des tests unitaires ne le font pas parce qu'ils ne savent tout simplement pas quoi faire. Donnez-leur quelques exemples de vos bons tests, et à quel point ils sont faciles à écrire et ils vont venir.
Nous avons reçu notre première erreur de compilation dans la base de code aujourd'hui. Je vois une grande opportunité. Un outil CI à tout le moins.
IMHO, tests unitaires ou tout autre test de cette matière (à l'exception des tests fonctionnels) doit être exécuté fréquemment contre des parties de l'application critique et volatile, en même temps. En d'autres termes, des tests unitaires ne doivent pas être écrits pour des tests d'écriture, mais plutôt pour assurer que les ingénieurs de développement / de maintenance ne tristent pas sur certaines conditions dans le code.
Cela dit, vous voudrez peut-être également jeter un coup d'œil aux tests d'intégration exécutés dans un serveur CI, de plus en plus, car ils sont plus proches des tests fonctionnels, ainsi que parce que le code est mature. De mes observations, identifier les tests d'unité à écrire dans une application mature est beaucoup difficile et a moins de retour sur investissement inférieur au terme plus court que les tests d'intégration.
Les tests d'intégration dans votre cas garantiront que les différents niveaux de l'application continuent de se tenir ensemble avec les intentions des développeurs d'origine. Des tests unitaires d'autre part, être un peu plus localisé dans la nature garantira que tout nouveau correctif de correctif / bogue dans une zone donnée provoque des effets secondaires à cet endroit.
Ce sera un effort et des retours énormes seraient petits. Automatisez plutôt et développez vos tests actuels pour assurer la stabilité du système (je suppose qu'il existe des tests au niveau du système). Je pense que vous devriez vous concentrer sur des parties du système qui constatent encore beaucoup de changement ou que vous prévoyez de changer dans un proche avenir.
Le test unitaire est bon mais peut être difficile à rénirmer dans un système existant. Si vous vous concentrez simplement sur les tests unitaires pour l'année prochaine ou plus, vous allez perdre de l'avant.
Je n'écrirais pas des tests juste pour écrire des tests. Quel serait le gain d'entreprise? Votre entreprise a probablement déjà souffert des effets de ne pas avoir d'essais unitaires et que les problèmes ont maintenant été abordés. Si j'ai ajouté des tests, je ne les ajouterais aux sections du code susceptibles de causer les résultats les plus désagréables. Par exemple, j'envisagerais d'ajouter des tests à tout numéro de rôle / de sécurité.
La situation que l'O.P. a décrit est un problème de "changement de mentalité". À l'heure actuelle, forçant vos coéquipiers à adopter une habitude particulière ne fonctionne pas. Vous devez semer la véritable motivation dans les développeurs et dans les intervenants d'entreprise pour en faire une adoption naturelle. Mes suggestions:
Je viens de découvrir qu'il existe un mini-projet distinct avec seulement des cas de test. Ce sont un très petit nombre de tests et vraisemblablement une partie d'un effort ancien pour traverser des tests hors de la liste en attente. En outre, ils n'offrent aucune garantie de code, car ils ne fonctionnent pas chaque fois que le code est compilé. Les efforts de rédaction de tests frais ne sont pas aidés par le fait que le code n'a pas été écrit avec des tests automatisés à l'esprit - les parties n'ont aucune possibilité d'insérer des objets à tester / simulaires, et un important cadre faux peut être évolué. Mais je suppose que le consensus jusqu'à présent est de persister avec de nouveaux tests?