{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Tests unitaires dans les SGBD \u2014 comment nous proc\u00e9dons chez Sportmaster, deuxi\u00e8me partie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Premi\u00e8re partie \u2014 ici<\/a><\/noindex>.<\/i><\/p>\n

\"Tests<\/a><\/noindex><\/p>\n

Imaginez la situation. Vous devez d\u00e9velopper une nouvelle fonctionnalit\u00e9. Vous avez des travaux ant\u00e9rieurs de vos pr\u00e9d\u00e9cesseurs. Si l'on suppose que vous n'avez aucune obligation morale, que feriez-vous ?<\/p>\n

Le plus souvent, tous les anciens travaux tombent dans l'oubli et tout commence \u00e0 z\u00e9ro. Personne n'aime fouiller dans le code des autres, et s'il y a du temps, pourquoi ne pas se lancer dans la cr\u00e9ation de son propre syst\u00e8me ? C'est une approche typique, et elle est en grande partie correcte. Mais dans notre projet, nous n'avons pas agi ainsi. Nous avons bas\u00e9 notre futur syst\u00e8me de tests automatis\u00e9s sur les travaux de unit-tests en utPLSQL de nos pr\u00e9d\u00e9cesseurs, puis nous avons avanc\u00e9 sur plusieurs fronts en parall\u00e8le.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Restauration des anciens unit-tests.<\/b> Par restauration, nous entendons l'adaptation des tests \u00e0 l'\u00e9tat actuel du syst\u00e8me de fid\u00e9lit\u00e9 et l'adaptation des tests aux normes utPLSQL. <\/li>\n
  2. R\u00e9solution du probl\u00e8me de compr\u00e9hension de ce qui est couvert par des tests automatis\u00e9s, c'est-\u00e0-dire quels m\u00e9thodes et processus le sont. <\/b>Il faut soit garder cette information en t\u00eate, soit tirer des conclusions bas\u00e9es sur le code des tests automatis\u00e9s. C'est pourquoi nous avons d\u00e9cid\u00e9 de cr\u00e9er un catalogue. \u00c0 chaque test automatis\u00e9, nous avons attribu\u00e9 un mn\u00e9motechnique unique, r\u00e9dig\u00e9 une description et not\u00e9 les param\u00e8tres (par exemple, dans quelles conditions il doit \u00eatre ex\u00e9cut\u00e9, ou ce qui doit se passer si le test \u00e9choue). En gros, nous avons rempli les m\u00e9tadonn\u00e9es sur les tests automatis\u00e9s et les avons plac\u00e9es dans les tables standard du sch\u00e9ma utPLSQL.<\/li>\n
  3. D\u00e9termination de la strat\u00e9gie d'expansion, c'est-\u00e0-dire le choix des fonctionnalit\u00e9s \u00e0 v\u00e9rifier avec des tests automatis\u00e9s.<\/b> Nous avons d\u00e9cid\u00e9 de nous concentrer sur trois choses : les nouvelles am\u00e9liorations du syst\u00e8me, les incidents en production et les processus cl\u00e9s du syst\u00e8me. De cette mani\u00e8re, nous nous d\u00e9veloppons parall\u00e8lement aux versions, assurant une qualit\u00e9 sup\u00e9rieure de celles-ci tout en \u00e9largissant la port\u00e9e des tests de r\u00e9gression et en garantissant la fiabilit\u00e9 du syst\u00e8me dans des endroits critiques. Le premier point critique fut le processus de distribution des remises et des bonus par facture.<\/li>\n
  4. Naturellement, nous avons commenc\u00e9 \u00e0 d\u00e9velopper de nouveaux tests automatis\u00e9s. <\/b>Une des premi\u00e8res t\u00e2ches de publication a \u00e9t\u00e9 d'\u00e9valuer les performances des \u00e9chantillons pr\u00e9d\u00e9finis du syst\u00e8me de fid\u00e9lit\u00e9. Dans notre projet, nous avons un bloc de requ\u00eates SQL rigoureusement d\u00e9finies qui s\u00e9lectionnent les clients selon des crit\u00e8res. Par exemple, obtenir une liste de tous les clients dont le dernier achat a \u00e9t\u00e9 effectu\u00e9 dans une ville sp\u00e9cifique, ou une liste de clients dont le montant moyen des achats est sup\u00e9rieur \u00e0 une certaine valeur. En \u00e9crivant des tests automatis\u00e9s, nous avons v\u00e9rifi\u00e9 ces \u00e9chantillons pr\u00e9d\u00e9finis et avons enregistr\u00e9 des param\u00e8tres de performance de r\u00e9f\u00e9rence, de plus, nous avons mis en place des tests de charge.<\/li>\n
  5. Le travail avec les tests automatis\u00e9s doit \u00eatre pratique.<\/b>. Deux actions sont effectu\u00e9es le plus souvent : le lancement des tests automatis\u00e9s et la cr\u00e9ation de donn\u00e9es de test. Ainsi, deux modules auxiliaires ont \u00e9t\u00e9 cr\u00e9\u00e9s dans notre syst\u00e8me : un module de lancement et un module de g\u00e9n\u00e9ration de donn\u00e9es.\n

    Le module de lancement se pr\u00e9sente sous la forme d'une proc\u00e9dure universelle avec un unique param\u00e8tre textuel d'entr\u00e9e. En tant que param\u00e8tre, on peut transmettre un code mn\u00e9motechnique de test automatis\u00e9, le nom d'un paquet, le nom d'un test, la configuration du test automatis\u00e9 ou un mot-cl\u00e9 r\u00e9serv\u00e9. La proc\u00e9dure s\u00e9lectionne et lance tous les tests automatis\u00e9s r\u00e9pondant aux conditions.<\/p>\n

    Le module de g\u00e9n\u00e9ration de donn\u00e9es est pr\u00e9sent\u00e9 sous la forme d'un paquet, dans lequel pour chaque objet du syst\u00e8me \u00e0 tester (table dans la BDD), une proc\u00e9dure sp\u00e9ciale a \u00e9t\u00e9 cr\u00e9\u00e9e pour y ins\u00e9rer des donn\u00e9es. Dans cette proc\u00e9dure, les valeurs par d\u00e9faut sont maximis\u00e9es, ce qui permet de cr\u00e9er des objets en un clin d'\u0153il. De plus, des mod\u00e8les de donn\u00e9es cr\u00e9\u00e9es ont \u00e9t\u00e9 \u00e9labor\u00e9s pour plus de confort d'utilisation. Par exemple, cr\u00e9er un client d'un certain \u00e2ge avec un num\u00e9ro de t\u00e9l\u00e9phone de test et un achat effectu\u00e9.<\/li>\n

  6. Les tests automatis\u00e9s doivent \u00eatre lanc\u00e9s et fonctionner dans un d\u00e9lai acceptable pour votre syst\u00e8me. <\/b>C'est pourquoi un lancement quotidien nocturne a \u00e9t\u00e9 organis\u00e9, dont les r\u00e9sultats sont compil\u00e9s dans un rapport et envoy\u00e9s \u00e0 toute l'\u00e9quipe de d\u00e9veloppement par e-mail d'entreprise. Apr\u00e8s la restauration des anciens tests automatis\u00e9s et la cr\u00e9ation de nouveaux, le temps total de fonctionnement \u00e9tait de 30 minutes. Une telle performance a satisfait tout le monde, car le lancement se faisait hors des heures de travail.\n

    Mais nous avons d\u00fb travailler sur l'optimisation de la vitesse de fonctionnement. La mise \u00e0 jour du syst\u00e8me de fid\u00e9lit\u00e9 en production se fait la nuit. Dans le cadre d'une des versions, nous avons d\u00fb proc\u00e9der \u00e0 des modifications urgentes durant la nuit. Une attente de trente minutes pour les r\u00e9sultats des tests automatis\u00e9s \u00e0 trois heures du matin n'a pas rendu heureux la personne responsable de la version (un salut chaleureux \u00e0 Alexey Vasyukov !), et le lendemain matin, de nombreux \u00e9loges ont \u00e9t\u00e9 adress\u00e9s \u00e0 notre syst\u00e8me. Toutefois, un objectif de cinq minutes a \u00e9t\u00e9 fix\u00e9 pour le temps de traitement.<\/p>\n

    Pour acc\u00e9l\u00e9rer les performances, nous avons utilis\u00e9 deux m\u00e9thodes : les tests automatis\u00e9s sont d\u00e9sormais ex\u00e9cut\u00e9s en trois flux parall\u00e8les, ce qui est tr\u00e8s pratique gr\u00e2ce \u00e0 l'architecture de notre syst\u00e8me de fid\u00e9lit\u00e9. Et nous avons renonc\u00e9 \u00e0 l'approche o\u00f9 le test automatis\u00e9 ne cr\u00e9e pas de donn\u00e9es de test, mais essaie de trouver dans le syst\u00e8me quelque chose d'ad\u00e9quat. Apr\u00e8s avoir effectu\u00e9 les modifications, le temps total de traitement a \u00e9t\u00e9 r\u00e9duit \u00e0 3-4 minutes.<\/li>\n

  7. Le projet de tests automatis\u00e9s doit pouvoir \u00eatre d\u00e9ploy\u00e9 sur diff\u00e9rents environnements.<\/b> Au d\u00e9but, nous avons essay\u00e9 d'\u00e9crire nos propres scripts batch, mais il est vite devenu \u00e9vident qu'une installation automatis\u00e9e maison \u00e9tait un v\u00e9ritable cauchemar, et nous nous sommes tourn\u00e9s vers des solutions industrielles. \u00c9tant donn\u00e9 qu'il y a beaucoup de code dans le projet (en priorit\u00e9, nous stockons le code des tests automatis\u00e9s) et tr\u00e8s peu de donn\u00e9es (les donn\u00e9es principales \u00e9tant les m\u00e9tadonn\u00e9es des tests automatis\u00e9s), l'int\u00e9gration de Liquibase dans le projet s'est r\u00e9v\u00e9l\u00e9e tr\u00e8s simple.\n

    C'est une biblioth\u00e8que open source ind\u00e9pendante de la base de donn\u00e9es pour le suivi, la gestion et l'application des modifications de sch\u00e9ma de base de donn\u00e9es. Elle est pilot\u00e9e par la ligne de commande ou des frameworks comme Apache Maven. Le principe de fonctionnement de Liquibase est assez simple. Nous avons un projet organis\u00e9 d'une mani\u00e8re particuli\u00e8re, qui se compose de modifications ou de scripts \u00e0 appliquer sur le serveur cible, ainsi que de fichiers de contr\u00f4le d\u00e9finissant l'ordre et les param\u00e8tres selon lesquels ces modifications doivent \u00eatre install\u00e9es. <\/p>\n

    Au niveau de la base de donn\u00e9es, une table sp\u00e9ciale est cr\u00e9\u00e9e o\u00f9 Liquibase stocke le journal des mises \u00e0 jour. Chaque modification a un hachage calcul\u00e9 qui est compar\u00e9 \u00e0 chaque fois entre le projet et l'\u00e9tat dans la base. Gr\u00e2ce \u00e0 Liquibase, nous pouvons facilement appliquer les modifications de notre syst\u00e8me sur n'importe quel environnement. Les autotests sont maintenant ex\u00e9cut\u00e9s dans les environnements de test et de release, ainsi que sur des conteneurs (environnements personnels des d\u00e9veloppeurs).<\/li>\n<\/ol>\n

    \"Tests
    \n
    \nAlors, parlons des r\u00e9sultats de l'application de notre syst\u00e8me de tests unitaires. <\/p>\n

      \n
    1. Bien s\u00fbr, tout d'abord, nous sommes convaincus que nous avons commenc\u00e9 \u00e0 d\u00e9velopper un logiciel de meilleure qualit\u00e9. Les autotests sont ex\u00e9cut\u00e9s quotidiennement et lors de chaque release, trouvant des dizaines d'erreurs. De plus, certaines de ces erreurs sont seulement indirectement li\u00e9es \u00e0 la fonctionnalit\u00e9 que nous souhaitions r\u00e9ellement modifier. Il y a de grands doutes quant au fait que ces erreurs auraient \u00e9t\u00e9 d\u00e9tect\u00e9es par des tests manuels. <\/li>\n
    2. L'\u00e9quipe a gagn\u00e9 en confiance quant \u00e0 la fonctionnalit\u00e9 sp\u00e9cifique qui fonctionne correctement\u2026 Cela concerne en premier lieu nos processus critiques. Par exemple, au cours des six derniers mois, nous n'avons eu aucun probl\u00e8me avec la distribution des remises et des bonus sur le re\u00e7u, malgr\u00e9 les changements fr\u00e9quents, alors qu'au cours des p\u00e9riodes pr\u00e9c\u00e9dentes, des erreurs survenaient avec une certaine r\u00e9gularit\u00e9.<\/li>\n
    3. Nous avons r\u00e9ussi \u00e0 r\u00e9duire le nombre d'it\u00e9rations de test. Gr\u00e2ce au fait que des autotests sont \u00e9crits pour la nouvelle fonctionnalit\u00e9, un code de meilleure qualit\u00e9 parvient aux analystes et, en m\u00eame temps, aux testeurs, car il a d\u00e9j\u00e0 \u00e9t\u00e9 v\u00e9rifi\u00e9.<\/li>\n
    4. Une partie des travaux de tests automatis\u00e9s est utilis\u00e9e par les d\u00e9veloppeurs. Par exemple, les donn\u00e9es test sur les conteneurs sont cr\u00e9\u00e9es \u00e0 l'aide d'un module de g\u00e9n\u00e9ration d'objets.<\/li>\n
    5. Il est \u00e9galement important de noter que nous avons eu une \u00ab acceptation \u00bb du syst\u00e8me de tests automatis\u00e9s de la part des d\u00e9veloppeurs. Il y a une compr\u00e9hension que c'est important et utile. En revanche, d'apr\u00e8s mon exp\u00e9rience, ce n'est vraiment pas le cas. Les autotests doivent \u00eatre \u00e9crits, maintenus et d\u00e9velopp\u00e9s, et les r\u00e9sultats doivent \u00eatre analys\u00e9s, alors que souvent ces investissements de temps ne valent tout simplement pas le coup. Il est beaucoup plus facile d'aller sur la production et de r\u00e9soudre les probl\u00e8mes l\u00e0-bas. Nos d\u00e9veloppeurs se mettent d\u00e9sormais en file et demandent \u00e0 ce que leur fonctionnalit\u00e9 soit couverte par des autotests.<\/li>\n<\/ol>\n

      Que faire ensuite<\/h2>\n

      \n\"Tests
      \n
      \nParlons des plans de d\u00e9veloppement du projet de tests automatis\u00e9s.<\/p>\n

      Sans aucun doute, tant que le syst\u00e8me de fid\u00e9lit\u00e9 de Sportmaster est vivant et continue \u00e0 \u00e9voluer, on peut \u00e9galement pratiquement d\u00e9velopper ind\u00e9finiment les tests automatiques. Par cons\u00e9quent, la principale direction de d\u00e9veloppement est l'\u00e9largissement de la couverture.<\/p>\n

      Avec l'augmentation du nombre de tests automatiques, le temps total d'ex\u00e9cution augmentera in\u00e9vitablement, et nous devrons de nouveau aborder la question des performances. Il est fort probable que la solution consistera \u00e0 augmenter le nombre de flux parall\u00e8les.<\/p>\n

      Mais ce sont des voies de d\u00e9veloppement \u00e9videntes. Si l'on parle de quelque chose de plus non trivial, soulignons ce qui suit :<\/p>\n

        \n
      1. Actuellement, la gestion des tests automatiques s'effectue au niveau de la base de donn\u00e9es, c'est-\u00e0-dire qu'il faut des connaissances en PL\/SQL pour travailler efficacement. Si n\u00e9cessaire, la gestion du syst\u00e8me (par exemple, le lancement de tests ou la cr\u00e9ation de m\u00e9tadonn\u00e9es) peut \u00eatre d\u00e9l\u00e9gu\u00e9e \u00e0 une interface d'administration, en utilisant Jenkins ou quelque chose de similaire.<\/li>\n
      2. Tout le monde aime les indicateurs quantitatifs et qualitatifs. Pour les tests automatis\u00e9s, un indicateur universel est la couverture de code ou la m\u00e9trique de couverture du code. Gr\u00e2ce \u00e0 cet indicateur, nous pouvons d\u00e9terminer quel pourcentage du code de notre syst\u00e8me \u00e0 tester est couvert par les tests automatiques. Depuis la version 12.2, Oracle offre des possibilit\u00e9s de calcul de cette m\u00e9trique et propose d'utiliser le package standard DBMS_PLSQL_CODE_COVERAGE.\n

        Notre syst\u00e8me de tests automatiques a un peu plus d'un an et peut-\u00eatre que c'est le moment id\u00e9al pour \u00e9valuer la couverture. Dans mon pr\u00e9c\u00e9dent projet (pas celui de Sportmaster), cela s'est av\u00e9r\u00e9 le cas. Un an apr\u00e8s avoir travaill\u00e9 sur les tests automatiques, la direction a demand\u00e9 d'\u00e9valuer quel pourcentage de code nous couvrons. Avec une couverture de plus de 1%, la direction serait heureuse. Nous, les d\u00e9veloppeurs, nous attendions un r\u00e9sultat d'environ 10%. Nous avons activ\u00e9 la couverture de code, mesur\u00e9, et obtenu 20%. Enjou\u00e9s, nous sommes partis chercher une prime, mais comment nous y sommes pris et o\u00f9 nous sommes all\u00e9s apr\u00e8s, c'est toute une autre histoire.<\/li>\n

      3. Les tests automatiques peuvent v\u00e9rifier les services Web expos\u00e9s. Oracle le permet tout \u00e0 fait, et nous ne rencontrerons plus un certain nombre de probl\u00e8mes. <\/li>\n
      4. Et bien s\u00fbr, notre syst\u00e8me de test automatis\u00e9 peut \u00eatre appliqu\u00e9 \u00e0 un autre projet. La solution que nous avons obtenue est universelle et n\u00e9cessite simplement l'utilisation d'Oracle. J'ai entendu dire qu'il y a de l'int\u00e9r\u00eat pour les tests automatis\u00e9s dans d'autres projets de Sportmaster et il est possible que nous nous rendions chez eux.<\/li>\n<\/ol>\n

        <\/p>\n

        Conclusions<\/h2>\n

        \nR\u00e9capitulons. Sur le projet de programme de fid\u00e9lit\u00e9 chez Sportmaster, nous avons r\u00e9ussi \u00e0 impl\u00e9menter un syst\u00e8me de test automatis\u00e9. La base de celui-ci est la solution utPLSQL de Steven Feuerstein. Autour de utPLSQL se trouvent le code des tests automatis\u00e9s et des modules auxiliaires \u00e9crits \u00e0 la main : module de lancement, module de g\u00e9n\u00e9ration de donn\u00e9es, et d'autres. Les tests automatis\u00e9s sont lanc\u00e9s quotidiennement et, ce qui est le plus important, ils fonctionnent et apportent des b\u00e9n\u00e9fices. Nous sommes convaincus que nous avons commenc\u00e9 \u00e0 produire des logiciels de meilleure qualit\u00e9. Par ailleurs, la solution obtenue est universelle et peut \u00eatre librement appliqu\u00e9e \u00e0 tout projet n\u00e9cessitant d'organiser des tests automatis\u00e9s sur une base de donn\u00e9es Oracle.<\/p>\n

        P.S. Cet article est plut\u00f4t g\u00e9n\u00e9ral : il contient beaucoup de texte et quasiment pas d'exemples techniques. Si le sujet vous int\u00e9resse globalement, nous sommes pr\u00eats \u00e0 le poursuivre et \u00e0 revenir avec un compl\u00e9ment, o\u00f9 nous expliquerons ce qui a chang\u00e9 au cours des six derniers mois et fournirons des exemples de code.<\/p>\n

        N'h\u00e9sitez pas \u00e0 laisser des commentaires s'il y a des points sur lesquels vous aimeriez que nous nous concentrions \u00e0 l'avenir, ou des questions n\u00e9cessitant une clarification.<\/i><\/p>\n

        Seuls les utilisateurs enregistr\u00e9s peuvent participer au sondage. Connectez-vous<\/a><\/noindex>, s'il vous pla\u00eet.<\/p>\n

        Continuons d'en parler ?<\/h2>\n