Dois-je demander des tests unitaires aux programmeurs? [fermé]

Je travaille dans un endroit où nous achetons beaucoup de projets informatiques. Nous produisons actuellement une norme pour les exigences des systèmes pour la réquisition de futurs projets. Dans ce processus, nous discutons si nous pouvons ou non exiger des tests unitaires automatisés de nos fournisseurs.

Je suis fermement convaincu que des tests unitaires automatisés appropriés sont le seul moyen de documenter la qualité et la stabilité du code. Tous les autres semblent penser que les tests unitaires sont une méthode facultative qui concerne uniquement le fournisseur. Ainsi, nous ne ferons aucune demande de tests unitaires automatisés, de tests continus, de rapports de couverture, d'inspections de tests unitaires ou de tout type. Je trouve cette politique extrêmement frustrante.

Suis-je totalement hors de propos ici?

Veuillez me fournir des arguments pour chacune des opinions.

Je crois fermement que des tests unitaires automatisés appropriés sont le seul moyen de documenter la qualité et la stabilité du code.

Le fait est que vous n'obtiendrez pas (ou très rarement au moins) des tests unitaires automatisés appropriés en les forçant sur les gens. C'est un bon moyen d'obtenir des tests de merde et d'augmenter le coût des projets.

Personnellement, je regarderais vers une certaine demande ou SLA qui implique la qualité; quelle que soit la façon dont cela est accompli. Il y a 10 ans, les tests unitaires étaient au mieux peu fréquents. Vous ne voulez pas menotter vos fournisseurs dans 10 ans lorsque nous avons de meilleures méthodes pour garantir la qualité, mais votre politique obsolète les oblige à utiliser l'ancienne méthode.

Personnellement, je pense que dans votre cas, vous devriez plutôt penser en termes de tests d'acceptation:

• Vous avez une boîte noire qui vous est attribuée et vous vous attendez à ce qu'elle se comporte d'une certaine manière.
• Vous ne paierez pas tant que ce n'est pas le cas.
• Écrivez des tests unitaires en exerçant le comportement que vous devez voir, et s'ils échouent, ils doivent le corriger.

Notez également qu'il s'agit d'une question de confiance. Si vous ne faites pas confiance à votre fournisseur, vous devez obtenir le code source, l'inspecter et le compiler vous-même. Rien de moins que cela signifie que vous leur faites au moins confiance quelques - uns .

Je crois fermement que des tests unitaires automatisés appropriés sont le seul moyen de documenter la qualité et la stabilité du code.

Cela me surprend à quel point cette pensée est courante. Automatisé, oui. Test unitaire (seul), non. Les tests de logiciels automatisés ne se limitent pas aux tests unitaires. Qu'en est-il de l'intégration, du système, de la fonctionnalité, de l'assurance qualité? Pour certaines raisons, les gens ont tendance à penser: "Ok, nous avons donc des tests unitaires appropriés. Terminé avec les tests, appelez-le vendredi soir!" . Les tests unitaires ne sont que le début.

Quoi qu'il en soit, revenons au sujet. Je suis d'accord avec les autres qui disent que forcer quoi que ce soit sur quiconque donnera probablement des résultats opposés à ceux souhaités. Vous ne savez jamais comment fonctionne l'équipe, peut-être qu'ils ont obtenu un service de test d'une valeur de un million de dollars et n'ont jamais écrit de test unitaire.

Lors de mon premier emploi, je travaillais dans un endroit où nous avions 0 tests unitaires (nous étions des tas de juniors à lancer des trucs plus ou moins sérieux). Croyez-le ou non, cela a fonctionné. Bien sûr, personne n'a été confié pourquoi ce bogue a été corrigé ou de ce que ce correctif a cassé, mais cela a fonctionné. Il y avait des moments où un bug absolument aléatoire sortait, maisbatte de baseball et risque d'incendie de votre appartementquelques heures supplémentaires peuvent faire des merveilles. Peut-être que vos fournisseurs utilisent des techniques similaires ?

Je doute beaucoup que votre direction soit disposée à payer pour des tests unitaires appropriés dans un contrat. Un test unitaire approprié coûte autant que le code qu'il teste, mais donne peu de valeur perçue à l'utilisateur final, de sorte qu'il ne sera pas considéré comme tout aussi précieux. Aucune entreprise de développement de la qualité ne sera prête à consacrer l'effort de développement à des tests unitaires pour un coût moindre que les autres pièces, car elles ne sont pas pénibles pour le travail, elles peuvent trouver plus de 2 contrats qui prennent le même temps sans aucun exigences de tests unitaires.

Les tests unitaires exigeants augmenteront probablement vos devis reçus à un niveau déraisonnable, et seront probablement la première concession faite pour obtenir un prix inférieur.

Le coût de l'absence de tests unitaires dépend de l'ampleur de l'extension / du support du code vous-même. Il serait également important d'inspecter des parties du code pour avoir une idée de la qualité.

Si vous achetez simplement les projets pour pouvoir les utiliser comme une bibliothèque tierce et ne croyez pas que vous les modifierez, le risque de code de moindre qualité est moindre, tant qu'il fonctionne réellement.

Il s'agit en fin de compte de décisions commerciales, même si vous devez vous assurer que la personne qui prend la décision est également au courant de l'évaluation technique. Si vous devez l'expliquer à la direction, expliquez-le, c'est comme acheter une voiture d'occasion. En fin de compte, c'est à l'acheteur de décider si cela en vaut la peine, mais l'apporter à un mécanicien est une bonne idée afin que vous sachiez que vous n'obtenez pas de citron.

Vous payez, vous pouvez demander ce que vous voulez, y compris des copies / rapports de tous leurs tests unitaires.

Vous pourriez même écrire les tests, ou au moins les spécifications du test vous-même.

Je suis d'accord avec votre point de vue en ce que c'est une très bonne mesure de la qualité du code. Si un fournisseur refusait cette demande, il sonnerait l'alarme, pourquoi ne voudraient-ils pas le faire - ils ont des normes de qualité peu élevées et prennent des raccourcis?

Vous avez absolument raison de dire que votre projet nécessite des tests unitaires automatisés, des tests continus, des rapports de couverture et des inspections de tests unitaires.

Cependant, les choses exigeantes n'atteindront pas les résultats souhaités comme d'autres l'ont détaillé.

Votre défi est d'expliquer et de persuader les gens - des compétences beaucoup plus difficiles!

Je commencerais d'abord par la direction, en expliquant les avantages et les inconvénients des tests et les avantages ultérieurs. Veuillez faire attention à ne pas communiquer l'émotion derrière des déclarations comme «J'écris des tests unitaires APPROPRIÉS» (en capitalisant le vôtre). Vous ne voulez pas «crier» les mots (comme ALL CAPS l'indique), vous allez persuader et convaincre les gens afin qu'ils choisissent eux-mêmes la bonne solution.

En fin de compte, si vous ne pouvez pas introduire ces méthodes et les faire adopter là où vous êtes, et si vous êtes aussi passionné par elles que vous le dites (ce qui est bien!), Je choisirais une autre entreprise car il y en a beaucoup qui apprécient ces choses et vous souhaite la bienvenue à bord. Assurez-vous simplement d'être à leur sujet lors des entretiens afin qu'ils sachent où se trouvent vos passions et si vous serez un bon candidat.

Imposer des tests automatisés à quelqu'un n'atteindra pas les résultats souhaités, comme l'ont souligné @Joachim Sauer et @Telastyn dans leurs commentaires. Pour beaucoup de gens, les tests unitaires automatisés sont un énorme changement dans leur façon de penser. Parce que beaucoup de gens écrivent du code qui fonctionne, mais qui n'est pas très testable. Je pourrais écrire une page Web ASP.NET où toute la logique, interroger la base de données, les règles métier, les objets, etc. est dans le code derrière. La page fonctionnera-t-elle? Oui. Est-il testable à l'aide de tests unitaires automatisés? Absolument pas. Si un fournisseur ne dispose pas de tests unitaires automatisés, il faudra beaucoup d'efforts pour apprendre à écrire correctement les tests unitaires et, à la suite de cela, réécrire ou reformuler leur code pour le rendre plus facilement testable. Il y a de fortes chances qu'ils vous répercutent ce coût.

Le fait est que le fournisseur vous offre un produit, que ce soit une application .dll ou Windows, et que vous vous attendez à ce qu'il fonctionne 99% du temps. Bien sûr, il y a des bugs ici et là, mais pour la plupart, cela devrait fonctionner. C'est une attente raisonnable, surtout si le fournisseur souhaite conserver votre entreprise. S'il s'agit d'une boîte noire, peu importe comment ils le font fonctionner, ils pourraient utiliser une vague humaine de testeurs, ou une salle pleine de singes frappant au hasard des clés. Tant que ça marche. Mais ils devraient vous fournir une sorte de documentation sur la façon de l'utiliser.

Cependant, s'ils vous ont donné le code source afin que vous puissiez le modifier, je m'attendrais à des tests unitaires. Je ne travaillerais pas avec une entreprise qui ne fournit pas de tests unitaires. Sinon, comment sauriez-vous qu'une modification que vous apportez ne fait pas durcir le tout?

Les tests unitaires indiquent comment ce fournisseur gère les risques pendant le cycle de développement. Ceux qui utilisent des tests unitaires valorisent la réduction du risque et la qualité de ces tests est une indication de la quantité de risque gérée.

Cela dit, les tests unitaires ne définissent pas le niveau de risque auquel le projet tente de s'attaquer. Il ne joue également aucun rôle dans la réduction des risques introduits par de mauvaises pratiques de programmation.

Par conséquent, vous pourriez avoir un fournisseur qui a des pratiques de test solides en place mais continue d'écrire du code très risqué tandis qu'un autre fournisseur qui ne fait aucun test mais écrit du code à faible risque. Si les deux fournisseurs proposent le même produit, il est préférable de choisir le fournisseur à faible risque.

Cela ne peut être évalué que par des entretiens, du mentorat et des connaissances sur les personnalités et les compétences des personnes impliquées avec ce fournisseur.

J'ai trouvé cet article sur l'achat de logiciels personnalisés très utile: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

La première question qu'ils recommandent de poser est de savoir si le fournisseur écrit des tests.

Convenant avec d'autres que les tests unitaires de demande conduiraient à des tests pour le plaisir de tester; quelque chose qui est très contraire à ce que vous voulez.

En cours de vérification de vos fournisseurs; demandez-leur quel est leur processus de développement , car les tests ne sont qu'une partie de ce processus.

Ont-ils un processus de construction automatisé? Adoptent-ils un paradigme de gestion? Ont-ils des testeurs correctement formés et une équipe indépendante d'assurance qualité ? Et les normes de documentation?

Ceux-ci vous aideront à juger de la qualité globale de leur processus, et à leur tour de la qualité de ce qu'ils produisent.

Il me semble que l'inclusion de cette exigence aurait peu d'avantages pratiques, car elle serait impossible à faire respecter.

Vous pouvez demander le code des tests réels ou un rapport indiquant quels tests réels ont été exécutés et réussis. S'il s'agit d'un projet propriétaire, le fournisseur ne voudrait probablement pas fournir cela, car il serait probablement très suggestif des détails du code, et pourrait hérisser d'être fait pour fournir des détails d'implémentation de bas niveau et dire comment faire leur emplois. À un moment donné, il doit y avoir une certaine confiance.

Si vous ne le faites pas, ils pourraient vous faire exploser, mais en cochant simplement la case à côté de "exécute une suite de tests unitaires" pour répondre à l'exigence en écrivant un seul test qui réussit si leur utilitaire se compile et s'exécute ou un semi-assimilé similaire effort.

Ainsi, alors que les tests unitaires automatisés sont une pratique louable, je ne pense pas qu'il soit pratique d'insister auprès de fournisseurs externes.

Comme de nombreuses personnes l'ont souligné, forcer les fournisseurs à écrire des tests unitaires (ou mieux, une combinaison de tests unitaires et d'intégration automatisés) pour remplir un contrat ne donnera probablement pas des résultats de haute qualité. D'un autre côté, je conviens que les tests automatisés sont de loin la meilleure méthode actuellement utilisée pour garantir la qualité du code.

Je pense que le code écrit avec des tests unitaires est beaucoup plus facile à maintenir que le code qui a été écrit en premier et auquel des tests unitaires ont été ajoutés plus tard. Il impose une modularité et des dépendances minimales. Des tests d' intégration sont également nécessaires pour vérifier l'exactitude du code, mais ils n'ont pas le même impact sur la qualité du code qu'il est écrit. Essentiellement, des tests d'intégration automatisés pourraient être ajoutés après coup, mais les tests unitaires ont le plus d'impact lorsqu'ils sont écrits avec le code d'origine.

Mon conseil pour votre situation est de rechercher des fournisseurs qui préfèrent écrire du code avec des tests unitaires, et de les choisir plutôt que des fournisseurs qui ont tendance à ne pas écrire de code avec des tests unifiés. Si la direction doit payer pour cela, mettez des tests automatisés dans le contrat, mais UNIQUEMENT SI LE VENDEUR EST UTILISÉ POUR ÉCRIRE DU CODE AVEC DES TESTS UNITÉS.

Obtenons les priorités en premier ...

Dans votre rôle de client, votre principale préoccupation n'est pas les tests unitaires

Si vous utilisez des fournisseurs qui produisent des logiciels pour vous, vous ne devriez vraiment pas vous inquiéter s'ils utilisent une méthodologie ou une autre. Votre enjeu est d'acquérir une sorte de solution qui vous aidera à atteindre vos objectifs. La seule chose à laquelle vous devriez vous soucier est de savoir si cette solution est acceptable ou non. C'est pourquoi nous avons des tests d'acceptation car il est de votre responsabilité de vous assurer d'obtenir ce que vous voulez. C'est au moment crucial de l'acceptation du client que l'argent sera transféré des poches de votre entreprise dans la poche du fournisseur.

Vous pouvez exiger des tests unitaires comme exigence de livraison, mais il y a plusieurs problèmes hérités avec eux, le plus grave est qu'il n'y a aucun moyen sûr de déterminer les métriques à l'avance:

• Quelle est la quantité acceptable de tests unitaires?

Doit-il y avoir 10 tests? Que diriez-vous de 100 tests? Que diriez-vous de 1000 tests? En fait, il est assez difficile de déterminer au début le nombre de tests dont vous aurez besoin. Le nombre réel est indéterminable vraiment ... comme le problème d'arrêt ... mais nous ne résolvons pas ce problème.

Vous voulez juste un logiciel qui a des tests unitaires afin que vous puissiez continuer le développement. Les tests unitaires ne disent pas encore ce que vous avez cassé, mais ils sont parfaitement adaptés pour vous dire quand le code a un bogue de régression.

• Qu'est-ce qu'un niveau de couverture de code acceptable?

"100%, bien sûr!" vous pensez. Malheureusement, cette métrique est trompeuse; même si vous disposiez d'une couverture de code à 100%, êtes-vous vraiment sûr que les choses fonctionnent comme prévu? Il est possible d'avoir une couverture à 100% mais ne pas être fait.

Ce que vous devez vraiment faire, c'est des tests exploratoires, c'est-à-dire trouver quelqu'un qui est vraiment bon pour casser des trucs et les laisser faire les tests. Pour trouver les bugs auxquels aucun développeur n'a même pensé.

De plus, 100% est parfois inaccessible avec des tests unitaires purs si vous avez des hacks de performances nécessaires et utilisez des modèles de conception difficiles à tester (recherchez "singleton" et "tdd" dans votre moteur de recherche préféré et vous trouverez quelques exemples).

Vous voulez que le logiciel livré fonctionne et le document de spécification est votre seule garantie.

Vous aurez besoin d' un niveau de test plus élevé

Votre document de spécification doit être vérifié d'une manière ou d'une autre. Chaque point doit être passé avec vos fournisseurs ayant des objectifs clairs et des critères d'acceptation. Une organisation QA qui fonctionne bien (ou un testeur génial si vous avez un budget et une portée limitée) fournirait les cas de test pour vérifier ces critères d'acceptation. Vous avez également besoin de quelqu'un pour vérifier ces critères d'acceptation.

Il existe plusieurs façons de vérifier vos objectifs, et si quelqu'un me dit que vous ne pouvez pas définir d'objectifs raisonnables de qualité, de performance et d'efficacité, je les frapperai dans la tête avec des livres volumineux et lourds sur les tests d'exploration, de performance et d'utilisabilité respectivement. Il peut être facile de surpasser les objectifs, mais les connaissances et la communication vous aideront à définir des objectifs réalistes.

Je ne suis pas avocat mais la plupart des contrats de projet (qui sont essentiellement la mère de toutes les spécifications du projet) que j'ai lus ont généralement un critère de rapport de défauts qui stipule le nombre de bogues jugés acceptables. Les bogues sont généralement déterminés en fonction de la gravité, les bogues qui se révèlent par QA ont une faible tolérance tandis que les imperfections mineures ont une tolérance élevée. Dans les projets réels, il est difficile d'exiger que le logiciel ait 0 défaut. Les délais mettent généralement un terme à cette pratique. C'est dans ces situations que vous devez commencer à négocier la portée.

La plupart des logiciels fournis que j'ai vus ne sont généralement pas livrés avec des tests unitaires. Vous pourriez faire valoir que les fournisseurs devraient être suffisamment professionnels pour le faire, mais la principale raison pour laquelle vous voulez que les tests unitaires vous soient livrés est de vous assurer que vous n'obtenez pas de bogues de régression et également d'activer le refactoring. Dans la vie réelle avec des projets dans des délais serrés, le fournisseur et le client réduiront la portée et les tests unitaires sortiront généralement de la fenêtre et seront supprimés de la liste des livrables requis.

C'est un peu triste que les logiciels open source de haut niveau soient livrés avec des tests unitaires, mais un développeur de logiciels professionnel ne peut pas, non?

Alors, quand, en tant que client, puis-je me soucier des tests unitaires?

Je dirais que la seule fois où vous vous soucieriez vraiment des tests unitaires est si le logiciel livrable est un composant autosuffisant qui n'est pas exécuté en tant que programme autonome, pour lequel le test le plus grossier que vous pouvez faire est un test unitaire . Les bibliothèques de classes seraient un type de produit pouvant être fourni avec des tests unitaires.

Comment savez-vous que les fournisseurs n'écrivent pas de tests unitaires.

Peut-être que la direction et le vendeur ont eu une réunion et le vendeur a dit que le code coûte X $ et les tests unitaires coûtent Y $. Penny pinching management a dit que nous voulions juste le code.

Le vendeur a quand même décidé de passer des tests unitaires (en raison de la qualité) et de ne pas les partager avec vous (en raison de l'avantage concurrentiel).

Vous devez maintenant apporter des modifications majeures au logiciel. Étant donné que vous possédez le code, vous pouvez le faire vous-même ou le louer à des prix compétitifs (pas nécessairement au fournisseur d'origine). Mais puisque vous n'avez pas acheté les tests unitaires, le fournisseur d'origine sera en mesure de faire un travail de qualité comparable à un prix moins cher pour n'importe quel concurrent.

Il y a beaucoup de projets qui sont très réussis malgré le fait qu'ils n'utilisent pas de tests unitaires. Il suffit de regarder le noyau Linux, c'est un projet gigantesque avec une complexité bien au-delà de ce que vous trouveriez dans n'importe quel projet normal, et cela fonctionne toujours. Donc, si le résultat est un bon logiciel, vous ne devriez pas vous soucier de la façon dont ils l'ont atteint.

Non, vous n'avez pas nécessairement besoin d'exiger des unités de test complètes et automatisées. Il est plus important qu'ils vous fournissent des documents de stratégie de test appropriés. Nous allons bien de cette façon.