Dans le projet auquel j'appartiens, je développe en écrivant des tests pour chaque méthode de classe (il est difficile de dire que c'est un test unitaire ...) et des tests pour chaque API. Le test utilise pytest. Puisque nous développons avec plusieurs membres, nous le fusionnerons, et s'il est poussé vers le référentiel, jenkins exécutera automatiquement le test avant le déploiement, et s'il réussit, nous le déploierons. Voici un résumé de ce qui est bon et douloureux (même si c'est toujours en cours) et ce qui, à mon avis, devrait être amélioré. (Ci-après, texte seulement!)
Je suis soulagé lorsque le test passe. Calmez-vous mentalement. Ceci est important pour un développement sain.
Vous n'êtes pas obligé de travailler en vous souciant toujours de "Le code que j'ai écrit est-il correct?"
Si un bug sérieux survient après le démarrage du service, il doit être traité rapidement et avec précision, et il perdra bien sûr sa réputation.
De plus, nous devons nous préparer au prochain service tout en y traitant.
Je veux éviter autant que possible une telle situation.
Vous pouvez écrire des tests et les exécuter automatiquement à chaque fois que votre code est fusionné afin de trouver rapidement le bogue et de le corriger lorsque vous en avez les moyens.
Lorsqu'une erreur se produit, vous pouvez remarquer une divergence dans les spécifications lors de la recherche de la cause.
Si cela est également découvert après sa sortie, ce sera un gros problème.
Il est très utile de pouvoir le détecter tôt.
Cela s'applique également aux données de base.
Lorsque des données sont créées auxquelles l'ingénieur ne s'attendait pas, vous pouvez vérifier quelle était l'intention de ces données et prendre des mesures.
--Je peux lire le code
Si vous apportez des corrections, vous pouvez lire le code écrit par les membres.
La révision du code se fait séparément, mais après cela, vous aurez l'occasion de lire le code, ce qui vous donnera des connaissances et découvrira les problèmes.
Le temps d'exécution du test deviendra de plus en plus long. En particulier, les tests méthode par méthode peuvent être très longs.
Il faut actuellement environ une heure pour tout exécuter (bien que les tests d'API prennent quelques minutes).
C'est correct, mais c'est aussi un problème.
Actuellement, j'exécute le test de la pièce corrigée dans mon environnement, et si le test réussit, jenkins fait tout.
Il existe deux causes principales d'erreurs dans votre projet.
L'une est une erreur causée par la mise à jour des données de base. L'autre est une erreur due à un changement de spécification.
Ce dernier est occasionnel, mais le premier se produit fréquemment et est honnêtement difficile à gérer.
En effet, les tests que nous écrivons sont étroitement liés aux données de base.
Pour donner un exemple simple, j'écris un test selon lequel si vous vendez un article avec l'ID 1, vous obtiendrez 100 yens. C'est pourquoi nous n'écrivons pas de "test unitaire" mais l'écrivons comme un test basé sur des classes.
Les données de base changent fréquemment pendant le développement.
Le prix de vente changera ou les données d'identification elles-mêmes disparaîtront.
Vérifiez les données de base à chaque fois et apportez des corrections (parfois une erreur se produit toujours et la cause est un bogue de code).
Je ne pense pas que ce soit une bonne chose, mais je profite également de la tranquillité d'esprit de comparer les résultats avec des chiffres précis.
Quand je suis occupé, il est difficile de commencer à réparer.
En conséquence, jenkins vous enverra toujours des notifications d'erreur.
Cela n'a pas de sens d'automatiser le test, donc l'équipe a pris la décision de le corriger au moins dès qu'une erreur de test API se produit.
Cependant, nous essayons de prendre en charge autant que possible les tests basés sur les classes.
--Tester la granularité
En fonction de la personne qui rédige le test, il peut s'agir simplement d'une vérification qu'aucune erreur ne se produit, ou d'un test qui compare les résultats en détail.
Lors du lancement d'un projet, il peut être préférable d'ajuster la granularité de cette zone.
Lorsque les données sont encore dans un état temporaire, écrivez un test qui permet au programme de fonctionner normalement, et lorsque les données sont créées, créez un test séparé pour la granularité du test d'intégration. Je me demande si tout va bien, non, prenez le temps pour cela. N'est-ce pas? J'ai pensé.
Le test basé sur la méthode dure environ une heure.
Il est encore en développement, donc j'ai encore du temps, mais je ne peux pas me permettre de trouver un bogue lors de la sortie, de le corriger, de le tester pendant une heure, puis de le refléter en production.
Qu'est-ce qui ne va pas?
En revenant sur le développement jusqu'à présent (bien qu'il soit encore en cours de développement), je voulais enfin dire que le test est bon. Cela peut être douloureux. La maintenance des tests est gênante. Mais si vous réussissez le test, vous vous sentirez heureux. Après la sortie, chaque fois que je le corrige, un autre bug sort ... Je ne pense pas que cela puisse être évité grâce à ce test. Si vous n'avez pas encore écrit de test, écrivons un test.
Cette fois, j'ai écrit sur la garantie de la sécurité du code, mais la prochaine fois, j'écrirai sur l'amélioration des performances. De plus, j'étudierai s'il existe un style d'écriture plus esthétique.
Recommended Posts