Tests unitaires dans un SGBD - comment nous le faisons dans Sportmaster, deuxième partie

Première partie - ici.

Imaginez une situation. Vous êtes confronté à la tâche de développer de nouvelles fonctionnalités. Vous avez l'expérience de vos prédécesseurs. En supposant que vous n'ayez aucune obligation morale, que feriez-vous ?

Le plus souvent, tous les anciens développements sont oubliés et tout recommence. Personne n'aime fouiller dans le code de quelqu'un d'autre, et si vous avez le temps, pourquoi ne pas commencer à créer votre propre système ? C'est une approche typique, et à bien des égards, elle est correcte. Mais dans notre projet, nous avons agi différemment. Nous avons basé le futur système de test automatisé sur les développements des tests unitaires sur utPLSQL de nos prédécesseurs, puis nous sommes allés travailler dans plusieurs directions parallèles.

1. Restauration des anciens tests unitaires. La récupération signifie l'adaptation des tests à l'état existant du système de fidélité et l'adaptation des tests aux normes utPLSQL.
2. Résoudre le problème en comprenant, et quoi exactement, quelles méthodes et quels processus, nous avons couvert avec des autotests. Vous devez soit garder ces informations dans votre tête, soit tirer des conclusions basées directement sur le code des autotests. Nous avons donc décidé de créer un catalogue. Nous avons attribué un code mnémonique unique à chaque autotest, créé une description et fixé les paramètres (par exemple, dans quelles conditions il doit être exécuté ou ce qui doit se passer si l'exécution du test échoue). Essentiellement, nous avons rempli les métadonnées sur les autotests et placé ces métadonnées dans les tables standard du schéma utPLSQL.
3. Définition de la stratégie d'expansion, c'est-à-dire sélection de fonctionnalité soumise à vérification par des autotests. Nous avons décidé de prêter attention à trois choses : les nouvelles améliorations du système, les incidents de production et les processus clés du système. Ainsi, nous développons en parallèle avec la version, garantissant sa meilleure qualité, élargissant simultanément la portée de la régression et assurant la fiabilité du système dans les endroits critiques. Le premier goulot d'étranglement était le processus de distribution des remises et des bonus par chèque.
4. Naturellement, nous avons commencé à développer de nouveaux autotests. L'une des premières tâches de la version consistait à évaluer les performances d'échantillons prédéfinis du système de fidélité. Notre projet comporte un bloc de requêtes sql rigidement fixées qui sélectionnent les clients en fonction des conditions. Par exemple, obtenez une liste de tous les clients dont le dernier achat a eu lieu dans une ville particulière, ou une liste de clients dont le montant moyen des achats est supérieur à une certaine valeur. Après avoir écrit des autotests, nous avons vérifié des échantillons prédéfinis, des paramètres de performances de référence fixes et, en plus, nous avons effectué des tests de charge.
5. Travailler avec des autotests devrait être pratique. Les deux actions les plus courantes sont l'exécution d'autotests et la génération de données de test. C'est ainsi que deux modules auxiliaires sont apparus dans notre système : le module de lancement et le module de génération de données.

   Le lanceur est représenté comme une procédure générique avec un paramètre de texte d'entrée. En tant que paramètre, vous pouvez passer un code mnémonique d'autotest, un nom de package, un nom de test, un paramètre d'autotest ou un mot-clé réservé. La procédure sélectionne et exécute tous les autotests qui remplissent les conditions.

   Le module de génération de données se présente sous la forme d'un package, dans lequel pour chaque objet du système testé (une table dans la base de données), une procédure spéciale a été créée qui y insère des données. Dans cette procédure, les valeurs par défaut sont remplies au maximum, ce qui garantit la création d'objets littéralement d'un simple clic de doigt. Et pour faciliter l'utilisation, des modèles pour les données générées ont été créés. Par exemple, créez un client d'un certain âge avec un téléphone de test et un achat terminé.

6. Les tests automatiques doivent s'exécuter et s'exécuter dans un délai raisonnable pour votre système. Par conséquent, un lancement nocturne quotidien a été organisé, sur la base des résultats duquel un rapport sur les résultats est généré et envoyé à toute l'équipe de développement par courrier d'entreprise. Après la restauration d'anciens autotests et la création de nouveaux, le temps d'exécution total était de 30 minutes. Une telle performance convenait à tout le monde, puisque le lancement a eu lieu pendant les heures creuses.

   Mais nous avons dû travailler sur l'optimisation de la vitesse de travail. Le système de fidélisation de la production est mis à jour la nuit. Dans le cadre d'une des releases, nous avons dû faire des changements en urgence dans la nuit. Une demi-heure d'attente des résultats des autotests à trois heures du matin n'a pas réjoui le responsable de la libération (bonjour ardent à Alexei Vasyukov!), Et le lendemain matin, beaucoup de mots chaleureux ont été dits envers notre système. Mais en conséquence, une norme de travail de 5 minutes a été établie.

   Pour accélérer les performances, nous avons utilisé deux méthodes : nous avons commencé à exécuter des autotests en trois threads parallèles, car cela est très pratique en raison de l'architecture de notre système de fidélité. Et nous avons abandonné l'approche lorsque l'autotest ne crée pas de données de test pour lui-même, mais essaie de trouver quelque chose d'approprié dans le système. Après avoir apporté des modifications, le temps de fonctionnement total a été réduit à 3-4 minutes.

7. Un projet avec des autotests doit pouvoir être déployé sur différents stands. Au début du voyage, il y a eu des tentatives d'écrire nos propres fichiers batch, mais il est devenu clair qu'une installation automatisée auto-écrite est une horreur totale, et nous nous sommes tournés vers des solutions industrielles. Du fait que le projet a beaucoup de code directement (tout d'abord, nous stockons le code des autotests) et très peu de données (les données principales sont des métadonnées sur les autotests), il s'est avéré très facile à intégrer dans le Projet Liquibase.

   Il s'agit d'une bibliothèque indépendante de base de données open source pour le suivi, la gestion et l'application des modifications de schéma de base de données. Géré via la ligne de commande ou des frameworks comme Apache Maven. Le principe de fonctionnement de Liquibase est assez simple. Nous avons un projet organisé d'une certaine manière, qui consiste en des modifications ou des scripts qui doivent être déployés sur le serveur cible, et des fichiers de contrôle qui déterminent dans quel ordre et avec quels paramètres ces modifications doivent être installées.

   Au niveau du SGBD, une table spéciale est créée dans laquelle Liquibase stocke le journal de rollback. Chaque changement a un hachage calculé qui est comparé à chaque fois entre le projet et l'état dans la base de données. Grâce à Liquibase, nous pouvons facilement déployer les modifications de notre système sur n'importe quel circuit. Les autotests sont désormais exécutés sur les boucles de test et de publication, ainsi que sur les conteneurs (boucles personnelles des développeurs).

Parlons donc des résultats de l'application de notre système de tests unitaires.

1. Bien sûr, tout d'abord, nous sommes convaincus que nous avons commencé à développer de meilleurs logiciels. Les autotests sont exécutés quotidiennement et détectent des dizaines de bogues à chaque version. De plus, certaines de ces erreurs ne sont qu'indirectement liées à la fonctionnalité que nous voulions vraiment changer. Il y a de forts doutes que ces erreurs aient été trouvées par des tests manuels.
2. L'équipe a acquis la certitude que certaines fonctionnalités fonctionnent correctement... Tout d'abord, cela concerne nos processus critiques. Par exemple, au cours des six derniers mois, nous n'avons eu aucun problème avec la distribution des remises et des bonus par chèque, malgré les modifications apportées à chaque version, bien que dans les périodes précédentes, des erreurs se soient produites avec une certaine fréquence.
3. Nous avons réussi à réduire le nombre d'itérations de test. Étant donné que les autotests sont écrits pour de nouvelles fonctionnalités, les analystes et les testeurs à temps partiel obtiennent un code de meilleure qualité, car ça a déjà été vérifié.
4. Une partie des développements des tests automatisés est utilisée par les développeurs. Par exemple, les données de test sur les conteneurs sont créées à l'aide du module de génération d'objets.
5. Il est important que nous ayons développé une « acceptation » du système de test automatisé par les développeurs. Il est entendu que cela est important et utile. Et d'après ma propre expérience, je peux dire que c'est loin d'être le cas. Les autotests doivent être écrits, ils doivent être maintenus et développés, les résultats analysés, et souvent ces coûts de temps n'en valent tout simplement pas la peine. Il est beaucoup plus facile d'aller à la production et de régler les problèmes là-bas. Dans notre pays, les développeurs font la queue et demandent à couvrir leurs fonctionnalités avec des autotests.

Quelle est la prochaine

Parlons des plans de développement du projet de tests automatisés.

Bien sûr, tant que le système de fidélité Sportmaster est vivant et continue à se développer, les autotests peuvent également être développés presque à l'infini. Par conséquent, la direction principale du développement est l'expansion de la zone de couverture.

Au fur et à mesure que le nombre d'autotests augmente, le temps total de leur travail augmentera régulièrement et nous devrons à nouveau revenir à la question des performances. Très probablement, la solution consistera à augmenter le nombre de threads parallèles.

Mais ce sont des voies évidentes de développement. Si nous parlons de quelque chose de plus non trivial, nous soulignons ce qui suit :

1. Désormais, les autotests sont gérés au niveau du SGBD, c'est-à-dire la connaissance de PL/SQL est requise pour un travail réussi. Si nécessaire, la gestion du système (par exemple, le lancement ou la création de métadonnées) peut être prise en charge par une sorte de panneau d'administration utilisant Jenkins ou quelque chose de similaire.
2. Tout le monde aime les indicateurs quantitatifs et qualitatifs. Pour les tests automatiques, un tel indicateur universel est la couverture de code ou la métrique de couverture de code. Grâce à cet indicateur, nous pouvons déterminer quel pourcentage du code de notre système sous test est couvert par les autotests. A partir de la version 12.2, Oracle offre la possibilité de calculer cette métrique et propose d'utiliser le package standard DBMS_PLSQL_CODE_COVERAGE.

   Notre système d'autotest a un peu plus d'un an et il est peut-être temps d'évaluer la couverture. Dans mon dernier projet (un projet qui n'est pas de Sportmaster), cela s'est produit. Un an après avoir travaillé sur les autotests, la direction s'est donné pour tâche d'évaluer quel pourcentage du code nous couvrions. Avec plus de 1% de couverture, la direction serait contente. Nous, les développeurs, attendions un résultat d'environ 10%. Nous avons bousillé la couverture du code, l'avons mesurée, avons obtenu 20 %. Pour célébrer, nous sommes allés chercher le prix, mais comment nous y sommes allés et où nous sommes allés plus tard est une histoire complètement différente.

3. Les autotests peuvent tester les services Web exposés. Oracle vous permet de le faire, et nous ne rencontrerons plus un certain nombre de problèmes.
4. Et, bien sûr, notre système de test automatisé peut être appliqué à un autre projet. La solution que nous avons reçue est universelle et ne nécessite que l'utilisation d'Oracle. J'ai entendu dire qu'il y a un intérêt pour les tests automatisés sur d'autres projets Sportmaster et, peut-être, nous irons vers eux.

résultats

Résumons. Sur le projet de système de fidélité chez Sportmaster, nous avons réussi à mettre en place un système de test automatisé. Sa base est la solution utPLSQL de Stephen Feuerstein. Autour d'utPLSQL se trouve le code des autotests et des modules auxiliaires auto-écrits : un lanceur, un module de génération de données, etc. Les autotests sont exécutés quotidiennement et, surtout, fonctionnent et profitent. Nous sommes convaincus que nous avons commencé à sortir des logiciels de meilleure qualité. Dans le même temps, la solution résultante est universelle et peut être librement appliquée à tout projet où il est nécessaire d'organiser des tests automatisés sur le SGBD Oracle.

PS Cet article s'est avéré peu précis : il y a beaucoup de texte et pratiquement pas d'exemples techniques. Si le sujet est globalement intéressant, alors nous sommes prêts à le poursuivre et à revenir avec une suite, où nous vous dirons ce qui a changé au cours des six derniers mois et donnerons des exemples de code.

Rédigez des commentaires s'il y a des points qui devraient être soulignés à l'avenir, ou des questions qui nécessitent une divulgation.

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Allons-nous écrire plus à ce sujet?

• Oui, bien sûr

• Non merci

12 utilisateurs ont voté. 4 utilisateurs se sont abstenus.

Source: habr.com