À propos du test

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!)

Bonne chose

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.

Chose épicée

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.

Ce que je pense devrait être amélioré

--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?

Résumé

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

À propos du test
À propos de la file d'attente
À propos de la fonction Déplier
À propos de la commande de service
À propos de la matrice de confusion
À propos du modèle de visiteur
Pour se préparer au test G 2020 # 2
À propos du module Python venv
tester
À propos de la fonction enumerate (python)
À propos du problème du voyageur de commerce
À propos de la compréhension du lecteur en 3 points [...]
À propos des composants de Luigi
À propos des fonctionnalités de Python
Tester la version du module argparse
Pensez au problème de changement minimum
AtCoder: Python: Papa, l'exemple de test.
À propos du problème du vendeur de patrouille commandé
[Python] Qu'est-ce que @? (À propos des décorateurs)
Tester l'adéquation de la distribution
À propos de la valeur de retour de pthread_mutex_init ()
À propos de la valeur de retour de l'histogramme.
À propos du type de base de Go
À propos de la limite supérieure de threads-max
À propos de l'option moyenne de sklearn.metrics.f1_score
À propos du comportement de yield_per de SqlAlchemy
À propos de la taille des points dans matplotlib
À propos de la liste de base des bases de Python
Pensez grossièrement à la fonction de perte
À propos de LangID
À propos de CAGR
À propos de virtiofs
À propos de python-apt
À propos de l'autorisation
À propos de sklearn.preprocessing.Imputer
À propos de Gunicorn
Test de Jack Bella
À propos de requirements.txt
À propos des paramètres régionaux
Test de charge acridienne
Ecrire le test dans la docstring python
Test Django
A propos du comportement de enable_backprop de Chainer v2
À propos de l'environnement virtuel de Python version 3.7
À propos de l'axe = 0, axe = 1
Notes diverses sur le framework Django REST
[OpenCV] À propos du tableau retourné par imread
À propos de l'importation
À propos de NumFOCUS, une organisation de support open source
Post test
Pensez grossièrement à la méthode de descente de gradient
[Python] Résumez les éléments rudimentaires du multithreading
À propos de numpy
À propos de l'environnement de développement que vous utilisez
À propos de pip
À propos de Linux
A propos des arguments de la fonction setup de PyCaret