Malgré le fait que les technologies de test unitaire existent depuis 30 ans (Kent Beck a écrit l'article «Simple Smalltalk Testing: With Patterns» en 1989), tous les programmeurs ne possèdent pas cette technologie et toutes les entreprises n'ont pas intégré le test automatique dans leur culture d'entreprise. . Malgré les avantages évidents des tests automatiques, la résistance comportementale est encore assez forte. Quiconque a essayé de mettre en œuvre des tests automatisés sait qu'il y a toujours une raison pour laquelle cela ne pourrait pas être fait.
À partir de mon expérience personnelle de mise en œuvre de méthodes de programmation fiables dans mon entreprise, dans les entreprises que j'ai consultées, communiquant lors de conférences, et également à partir de sources accessibles au public, j'ai formulé des objections et des résistances typiques qui entravent la mise en œuvre d'une culture de tests automatiques.
J'ai regroupé toutes les objections dans une pyramide de programmation fiable, qui comprend quatre niveaux:
- La culture professionnelle (le plus haut niveau, la base d'une programmation fiable) est un ensemble de normes, de règles non écrites, de croyances des employés qui le guident dans son travail. Par exemple: «L'envoi de code découvert par des tests vers le référentiel est mauvais», «Faire taire les erreurs trouvées dans le code est une honte».
- La gestion est les procédures, politiques, règles adoptées par l'organisation, ainsi que la volonté (décision) des dirigeants. Par exemple: «Chaque fonction d'application développée doit transmettre un code de révision. Aucune exception! ”
- Les méthodes sont des approches scientifiques, des méthodes pour résoudre un problème particulier. Par exemple: «Si la fonction de l'application est difficile à tester, vous devez augmenter la testabilité de l'application en appliquant le modèle d'Injection de dépendances.»
- Les technologies (le plus bas niveau) sont les langages de programmation, les bibliothèques, les frameworks, les outils. Par exemple, JUnit, Selenium, XCTest et ainsi de suite.
Pourquoi une telle division est-elle nécessaire? Parce que le problème d'un niveau est résolu par des méthodes du même niveau ou par des méthodes d'un niveau supérieur. Par exemple, s'il n'est pas habituel pour une organisation d'écrire des tests automatiques (le problème de la culture professionnelle), alors ce problème ne peut pas être résolu en décrivant le processus métier de test en détail (niveau «gestion») ou en installant un cadre moderne (niveau «technologie»). Je donne la garantie que dans une semaine, personne ne passera de tests, malgré le processus opérationnel approuvé.
Objections culturelles
«Mes programmes ne se cassent pas. Je ne vois pas la nécessité de faire des tests. "
J'ai entendu cette déclaration de débutants ou de programmeurs trop confiants.
Bien sûr, une fois qu'une fonction écrite ne peut pas se casser d'elle-même. Mais ici, il est important de comprendre qu'au fil du temps, le programme peut nécessiter un support, l'introduction de nouvelles fonctions ou des ajouts aux fonctions existantes. La complexité des programmes - le nombre de classes et les dépendances entre elles - est assez grande, et finalement, après avoir créé une nouvelle fonction ou amélioré une fonction existante, une erreur se produira tôt ou tard. Un test automatique permettrait de détecter une telle régression.
En outre, une telle objection peut souvent être entendue par des programmeurs novices qui n'ont aucun concept de test. Par exemple, seuls les plantages sont considérés comme une panne, pas des erreurs fonctionnelles.
Lors d'une des entrevues que j'ai menées, le dialogue suivant a eu lieu:
- Avez-vous les compétences des tests automatiques?
- Non, j'ai écrit des programmes simples, il n'y avait rien à casser.
- Quelle est votre motivation pour changer d'emploi?
- Je veux écrire des applications complexes.
Je sais très bien comment cela se termine. Le programmeur est réputé pour développer un programme plus complexe, mais il ne connaît pas les méthodes de test automatique, il ne peut pas tester l'application de manière qualitative et il ne peut pas faire face à l'échelle du projet, ce qui entraînera une interruption du projet, un dépassement de coût du développement et une perte de réputation. Parce que j'ai personnellement géré des projets, où je ne pouvais pas faire face à l'échelle du projet et je l'ai échoué précisément en raison du manque de tests automatiques.
Réticence à prendre la responsabilité de la qualité du code, des tests.
Les tests automatisés sont la seule source d'informations opérationnelles et objectives sur la véritable qualité d'un produit logiciel. En d'autres termes, le programmeur a toujours un superviseur derrière le dos, qui peut rendre compte à tout moment à la direction de la façon dont le programmeur fait son travail. Les tests automatisés vous permettent de lier la productivité du travail non pas avec des tickets fermés dans la Jira, mais avec la vraie qualité du produit logiciel. Et ici, vous devez déjà réfléchir à la façon d'écrire de manière fiable afin que chaque prochaine modification du code ne casse pas les fonctions existantes. Pour que chaque nouvelle fonction fonctionne non seulement dans le script, quand tout va bien, mais traite également correctement les erreurs.
La responsabilité est l'engagement volontaire d'assurer un résultat positif du travail. L'employé accepte cette obligation en raison de son caractère et de sa formation. Malheureusement, en raison de la crise culturelle et professionnelle, tous les programmeurs ne sont pas prêts à assumer de telles obligations.
"Écrivez maintenant sans erreurs"
Les personnes qui ne connaissent pas très bien le fonctionnement du développement logiciel peuvent avoir une attitude négative envers les développeurs qui mentionnent une sorte d'erreurs.
- Couvrons l'application avec des tests automatiques.
- Pourquoi?
- Pour vous assurer que tout fonctionne correctement et qu'il n'y a pas d'erreurs.
- Ecrivez-vous avec des erreurs? Avez-vous de faibles qualifications? Écrivez tout de suite sans erreurs.
"Oui, mais tout le monde fait des erreurs ..."
- Mais la société XYZ a dit à un ami qu'ils ont des programmeurs de haut niveau qui écrivent sans erreur!
Ainsi, le développement de tests est difficile à «vendre» à des clients qui ne sont pas techniquement avertis. En conséquence, la direction est obligée de développer un projet sans tests automatiques, ce qui conduit à des problèmes bien connus.
Objections de gestion
«Avec les tests, écrire un programme est deux fois plus long. Nous ne respecterons pas les délais. »
À première vue, cette thèse semble juste. Il est vraiment nécessaire de passer du temps à programmer des tests. Mais les programmeurs et la direction ne tiennent pas compte du fait que le temps total de développement du produit comprend non seulement la programmation, mais le débogage et le support, ainsi que le coût énorme des tests de régression manuelle après avoir effectué des corrections.
Les tests automatisés ont plusieurs fonctions:
- Vérification .
1.1. Les tests vérifient que l'objet de test fonctionne correctement.
1.2. Les tests vérifient la qualité du travail du programmeur: si la tâche est résolue, s'il y a des effets secondaires sous forme de régressions. - Diagnostic . Les tests de diagnostic peuvent réduire considérablement le temps de recherche d'un défaut. Les tests vous permettent de déterminer l'emplacement de l'erreur, précis pour la classe et la méthode, et parfois précis pour la ligne de code.
- Automatiser . Les tests vous permettent d'entrer rapidement et facilement l'objet de test dans l'état souhaité pour le débogage.
- Documenter .
4.1. Les tests d'acceptation enregistrent les exigences du client pour le produit en cours de développement.
4.2. Les tests montrent des exemples d'utilisation du composant développé, réduisant ainsi le temps passé à étudier le travail du système par un autre programmeur.
Dans l'une des organisations que j'ai consultées, le responsable a résisté à l'introduction d'une culture de tests automatiques:
- Mais après tout, écrire des tests depuis longtemps! Nous ne respecterons pas les délais!
- Avez-vous des erreurs que vous recherchez et corrigez depuis très longtemps?
- Oui, il y en a.
- Quel est le cas le plus difficile?
- Nous avons recherché une erreur pendant 80 heures.
- 80 heures, c'est deux semaines de travail du programmeur. Si vous passiez même une semaine entière à tester l'automatisation, cela vous ferait gagner des mois pour diagnostiquer et déboguer votre application!
Notre organisation a le postulat: «Avec les tests, écrire un programme est deux fois plus rapide!» et ce postulat n'est pas discuté. Seul le coefficient 2 est discuté - parfois il y a 3 et 4. Et certains projets ne peuvent tout simplement pas être achevés sans tests automatiques compétents (voir le projet débordé).
"Nous avons déjà un département de tests manuels, laissez-les tester."
À première vue, la séparation des spécialisations entre tests et programmation semble logique.
Mais regardons les inconvénients des tests manuels:
- C'est très cher.
- Cela prend très longtemps. Par exemple: le script de test pour le testeur d'application mobile «Cinéma en ligne» fait 40 heures. Et ce n'est que pour une seule plateforme! Si vous devez tester l'application sur iPhone, iPad, Apple TV, Android, Fire TV, vous devez passer 40 × 6 = 240 heures de temps de travail, c'est un mois et demi, ce qui est inacceptable pour de courts cycles de développement.
- Les tests manuels sont sujets à des erreurs humaines courantes - ils ne donnent pas un résultat objectif et vrai.
De plus, certains types de tests ne peuvent pas être effectués dans un délai raisonnable, car le nombre de combinaisons de formats et de divers scripts de test est très important. Par exemple:
- Fonction permettant d'importer des fichiers CSV.
- Analyseurs pour les documents texte.
- Instruments financiers.
Objections au niveau de la méthode
Ignorance des méthodes de test automatique.
En raison de la crise de l'éducation, il n'y a pas de disciplines de tests automatiques dans les universités. Il existe très peu de cours de ce type dans les écoles informatiques commerciales. Et les cours existants sont superficiels et de mauvaise qualité. Par conséquent, j'ai souvent rencontré une stupeur chez les programmeurs: ils ne savent pas comment tester des applications non triviales (plus difficile que 2 + 2 = 4).
En fait, la science des tests est assez vaste. Par exemple, tous les programmeurs ne répondront pas immédiatement aux questions: a) qu'est-ce que la testabilité? b) qu'est-ce que la contrôlabilité et l'observabilité? c) quels modèles de conception améliorent la testabilité de l'application? Et ainsi de suite.
Les programmeurs ne savent pas ce qu'ils écrivent, à quoi cela ressemble, quelles seront les fonctions et les interfaces.
Il est très difficile de tester ce qui n'est pas clair à première vue. En d'autres termes, sans les exigences prédéfinies de l'application, le programmeur ne peut pas comprendre ce qu'on attend de lui.
La particularité de certains projets est qu'ils sont développés à l'aide de la technologie de produit minimum viable, qui en d'autres termes peut être décrite comme suit: "Faisons au moins quelque chose pour le temps minimum et le budget minimum", et le programmeur est considéré par le client ou la direction comme un analyste, concepteur, architecte, programmeur et testeur dans une bouteille. Avec cette approche, l'étape formelle de conception d'un système logiciel est exclue: la définition de la logique métier, du domaine, des interfaces des composants, ainsi que leur organisation interne de leur relation entre eux. Il n'y a pas d'architecture formalisée, pas d'interfaces, pas de processus métier prescrits - on ne sait pas quoi tester, à travers quelles interfaces et quel est le résultat attendu.
Code inapproprié.
La testabilité est une propriété de projet qui indique avec quelle facilité elle peut être testée. L'aptitude au test est déterminée par deux autres propriétés: la contrôlabilité et l'observabilité. Gérabilité - une propriété qui détermine la facilité avec laquelle il est possible d'entrer une application dans l'état souhaité pour les tests (remplir les conditions préalables). Observabilité - avec quelle facilité il est possible de considérer l'état après le test, de le comparer avec celui attendu.
Par exemple, l'authentification à deux facteurs à l'aide de SMS est très difficile à tester automatiquement, car la fonction de réception de SMS est en dehors de la portée de l'environnement de test automatisé. Un tel système ne convient pas.
Face à un système inadapté, le programmeur abandonne et évite de tester un tel système.
Préparation des données de test.
L'une des résistances non évidentes est la préparation des données de test et des normes. Par exemple: l'état initial de la base de données sur laquelle les tests sont effectués. La préparation des données de test peut prendre beaucoup de temps et de travail de routine, donc ce travail est considéré comme ingrat et sans intérêt parmi les programmeurs.
Solution:
- développement de valeurs de référence et d'exemples au stade de l'élaboration des tests d'acceptation - ils aideront également à résoudre les conflits avec le client au stade de l'acceptation du travail;
- élaboration de valeurs de référence au stade de la conception du système. Par exemple, les requêtes et réponses HTTP standard - faciliteront l'intégration du client et du serveur;
- développement de procédures spéciales d'assemblage de bases de données, dans lesquelles l'état requis de la base de données est créé automatiquement et non manuellement
- utilisation du modèle Object Mother [Fowler, Schuh, Peter et Stephanie Punke. "Faciliter la création d'objets de test sous XP." XP Universe. 2003], ce qui permet d'allouer et d'initialiser facilement des objets dans l'état requis.
Service de test.
Au cours de l'élaboration d'un projet, les exigences de celui-ci (clarification, changement) peuvent changer. Ou une refactorisation interne peut se produire, ce qui entraînera un changement dans les interfaces de classe. Avec le changement des exigences, les critères d'acceptation d'une fonction particulière changeront également, et avec eux les tests. À un moment donné, le programmeur peut refuser de réparer les tests, c'est-à-dire de les maintenir à jour.
Solution:
- utiliser le modèle «adaptateur» afin de découpler la logique du test de l'interface qu'il teste;
- utilisation de tests de haut niveau (cornichons, concombres, donnés à la demande);
- voir la solution à la résistance «préparation des données de test».
Conclusion
Il ne fait aucun doute que les logiciels doivent être fiables: dépasser les attentes des clients. Les tests automatisés ne sont pas le seul, mais un élément important dans le développement de logiciels fiables.
J'ai formulé des objections et des obstacles typiques à la mise en œuvre des tests automatiques, que j'ai personnellement rencontrés dans mon organisation, ainsi que dans les organisations que j'ai consultées.
L'article ne décrit que les problèmes et aborde à peine les moyens de les résoudre. En général, la stratégie pour résoudre ces problèmes me semble être la suivante:
- Formation et promotion d'une nouvelle culture de la conception informatique, qui est la fiabilité, la fierté et la responsabilité personnelle du résultat.
- Développer de nouvelles normes élevées pour les tests de code.
- Développement et mise en place de formations.
- L'introduction de la motivation dans la carrière des programmeurs et managers, liée à la qualité des produits logiciels en cours de développement, ainsi qu'aux compétences des tests automatiques.
La chose la plus importante que j'ai réussi à comprendre est que les problèmes se situent à différents niveaux: technologique, méthodologique, managérial et culturel. Et ils doivent être traités aux niveaux appropriés. Il est très difficile de mettre en œuvre des tests automatisés si le programmeur n'est pas formé aux méthodes de conception adaptées aux tests ou si la direction ne prend pas en charge une culture de programmation fiable dans l'organisation.
Je serai reconnaissant pour des exemples tirés de votre pratique de la facilité ou de la difficulté à mettre en œuvre des tests automatisés dans votre organisation. Quels problèmes avez-vous rencontrés? Comment les avez-vous résolus?