Une histoire sur un ingénieur salarié qui travaille pour une entreprise qui n'a pas de culture de code de test et qui travaille dur pour diffuser la culture de test tout en demandant le teint du manager. À la fin de l'article, j'écris le point de vue lors de la révision du code du test.
«C'est un projet de lancement. L'idée d'écrire le code de test en équipe en un mot du manager a été rejetée. Je pourrais comprendre pourquoi je ne devrais pas partir à l'aventure parce que je n'ai pas le savoir-faire pour écrire du code de test en interne. Cependant, il devrait être acceptable d'écrire un test pendant mon temps libre, alors j'ai décidé de faire de mon mieux.
Quand j'ai demandé à un ingénieur que j'étais au courant, il y avait environ deux personnes qui avaient passé un test. Je ne lui dirai pas, mais il sera certifié en tant que mentor et vous enseignera des méthodes efficaces et un savoir-faire avec Python et Django. Avec le recul, je pense que j'ai été béni avec l'environnement. Adopté Pytest, qui a plusieurs cadres de test pour Python mais a une solide documentation officielle. Pytest est très fonctionnel et la documentation est compliquée, donc je pense que vous pouvez apprendre à l'utiliser avec des exemples et à l'utiliser comme dictionnaire.
Installer pytest
pip install pytest
échantillon de test pytest
# -*- coding: utf-8 -*-
from __future__ import absolute_import, unicode_literals
#Fonction à tester
def add(a, b):
return a + b
#Code de test Le nom de la fonction est test_Comment commencer avec pytest
def test_add():
assert add(1, 1) == 2
assert add(1, 2) != 2
Résultat d'exécution du pytest
>>> $ py.test ../tests/test_add.py
=============================================================================== test session starts ===============================================================================
platform darwin -- Python 2.7.5 -- py-1.4.31 -- pytest-2.7.0
rootdir: /Users/***********, inifile: pytest.ini
plugins: cache, django, pep8, pythonpath
collected 2 items
../tests/test_add.py ..
============================================================================ 2 passed in 0.06 seconds =============================================================================
Au début, j'ai travaillé dur pour écrire un test unitaire, mais il semble que la charge du développeur soit lourde. On a l'impression d'essayer trop fort. Quand je l'ai consulté, il m'a conseillé de faire un test de boîte noire sur une base API Web au lieu d'un test basé sur la fonction sur un serveur Soshage. Quand je l'ai essayé, l'effort de développement était petit, simple et puissant. Je l'utilise toujours. La couverture du code ne s'est pas améliorée, mais les tests d'API Web peuvent couvrir l'API avec moins d'effort.
Cette méthode de test est particulièrement utile dans les langages de script, où vous trouverez souvent le type de bogues détectés au moment de la compilation.
Code Pytest pour tester l'API Web de style JSON
# -*- coding: utf-8 -*-
from __future__ import absolute_import, unicode_literals
import ujson
import requests
def test_api():
#Tester l'API GitHub
url = "https://api.github.com/repos/vmg/redcarpet/issues?state=closed"
headers = {'Accept-Encoding': 'identity, deflate, compress, gzip',
'Accept': '*/*', 'User-Agent': 'python-requests/1.2.0',
'Content-type': 'application/json; charset=utf-8',
}
response = requests.get(url, headers=headers)
#Le code d'état HTTP est 200
assert response.status_code == 200
#Être capable d'analyser BODY avec json
data = ujson.loads(response.text)
#URL dans le tableau, state, created_L'existence de l'élément de at
for param in data:
assert 'url' in param
assert 'state' in param
assert 'created_at' in param
résultat de l'exécution du test pytest
>>> $ py.test ../tests/test_webapi.py
=============================================================================== test session starts ===============================================================================
platform darwin -- Python 2.7.5 -- py-1.4.31 -- pytest-2.7.0
rootdir: /Users/*****, inifile: pytest.ini
plugins: cache, django, pep8, pythonpath
collected 2 items
../tests/test_webapi.py ..
============================================================================ 2 passed in 0.87 seconds =============================================================================
Une fois tous les tests API du serveur terminés, nous avons établi une règle à consulter au sein de l'équipe et rédiger le test API Web. Puisque pytest a un mécanisme simple, toute personne disposant d'un exemple de code pourrait facilement l'apprendre. Cependant, il faut beaucoup de temps pour faire un travail boueux, comme signaler dans la revue jusqu'à ce qu'il soit corrigé, exécuter des tests régulièrement et corriger les erreurs, et informer les nouveaux participants. (Si vous le connaissez, lancez-le régulièrement? Je pense que vous pensiez qu'il s'agissait d'un test automatique avec crochet de validation. À ce moment-là, je pensais l'introduire, mais j'ai oublié de l'introduire sans devenir trop lourd. Les problèmes qui en résultent seront décrits plus loin. )
-Enabled pour exécuter tous les tests avec une seule commande (écrite par shell) ・ Afin de se développer confortablement, tous les tests ont été exécutés en 60 secondes. ・ Il a été décidé que le test passerait la condition d'achèvement des travaux dans la procédure de construction de l'environnement local. ・ Confirmé que le test a réussi lors de la révision du code ・ Lors du développement d'une nouvelle fonction, il est indispensable qu'un test soit joint au moment de la révision du code. ・ J'ai effectué un test régulièrement et je leur ai demandé de le réparer ou de le réparer.
L'application a été lancée avec succès et une culture de test a pris racine au sein de l'équipe. Le développement est effectué sur une base de pull request, avec le code de test joint sans le signaler. En raison de l'échec du test, nous avons trouvé une dépendance entre le module nouvellement développé et le module qui était considéré comme hors de portée de l'influence, et nous avons pu éviter le bogue de production.
En tant que règle de fonctionnement, la liste de contrôle au moment du déploiement indique toujours clairement que l'exécution des tests est effectuée, de sorte que l'habitude d'exécuter des tests dès la phase de développement a pris racine parmi les membres.
J'ai proclamé qu'il serait bon de tenir une session d'étude en interne et d'écrire un test. La raison (l'une des) du succès de notre projet était que nous avons écrit du code de test. Surtout dans l'entreprise, c'était efficace car je pouvais partager le code de test réel.
C'est un test du temps, et si vous continuez à l'utiliser pendant une longue période de temps, le code de test portera une dette technique. Un test enfant problématique qui doit être corrigé à chaque fois que vous apportez une modification, un test qui prend plus de 300 secondes pour s'exécuter une fois, et un code de test laissé en commentaire car une erreur s'est produite en raison d'un problème avec le code de test lui-même lors du déploiement à la hâte. Testez du code trop compliqué à corriger et vous ne savez pas ce que vous testez.
Cela fait un an que l'opération a commencé. Les tests qui se terminaient initialement en moins de 60 secondes prennent désormais 12 minutes. La règle pour exécuter le test lors du déploiement est également omise en raison de la latence. Beaucoup d'ingénieurs étaient des vétérans et l'équipe de débogage était excellente, donc les bogues n'ont pas augmenté. De nombreuses personnes ont écrit des tests pour la nouvelle demande d'extraction de module, mais la culture de test au sein du projet a décliné.
En raison de l'influence de la session d'étude interne et du fait que certains ingénieurs avaient déjà écrit le code de test individuellement, même si j'avais l'intention de commencer par moi-même, le nombre de nouveaux projets qui adoptent progressivement l'écriture de test en règle générale augmente. est allé. Je fais un test! Je pense qu'il est important de dire cela.
fin
Si vous négligez d'implémenter la logique métier, cela ne fonctionnera pas selon les spécifications, il est donc essentiel de l'implémenter, mais c'est plutôt bien même si vous n'implémentez ni n'exécutez le code de test. Je pense que la raison pour laquelle la culture du test a décliné est que l'équipe de développement est épuisée par la maintenance du test, je vais donc noter où elle a été épuisée.
Je pense que nous aurions dû relier le commit hook et jenkins, ou adopter TravisCI ou CircleCI et les tester automatiquement lorsqu'ils étaient validés. J'ai écrit sur l'utilisation de CircleCI dans Django dans cet article
L'équipe était épuisée par la maintenance du test, qui dépend de manière compliquée des données de base et échoue une fois toutes les deux fois en raison du problème du test lui-même. Je pense que des tests de mauvaise qualité auraient dû être jetés et réécrits pour des raisons de métabolisme.
Je ne peux pas attendre un test qui prend plus de 60 secondes. Étant donné que le rythme de développement sera lent, je pense que nous aurions dû réfléchir davantage pour pouvoir développer confortablement en considérant l'exécution parallèle des tests et en la divisant en deux couches comme le test rapide et le test complet.
Bien qu'une erreur se produise s'il est exploité pendant une longue période de temps, le nombre de variables sera aligné et la personne qui l'a écrite sera éloignée du projet, il est donc nécessaire de quitter l'élément de test du point de vue du test. Je pense que c'était.
C'est une mesure efficace pour les nouveaux participants. Si vous vérifiez si le test a réussi pour chaque pull request même après la construction, il sera corrigé rapidement.
Si vous procédez au développement basé sur une pull request, le contrôle sera efficace, vous pouvez donc éviter la situation où le nombre de codes non testés augmente et l'effet pédagogique est grand.
Lorsqu'un échec de test se produit, personne ne verra le résultat du test, nous donnerons donc la priorité à sa correction. Si quelqu'un le corrige à plein temps, cela ne s'améliorera pas pour toujours, donc cela peut être bon pour l'éducation si vous le transportez en service.
Si le temps d'exécution du test est lent, vous ne pourrez pas voir les résultats, vous devez donc prendre des mesures pour exécuter les tests en parallèle ou accélérer le test.
C'est le point de vue de vérifier la revue de code lors de la réception d'une pull request.
Automatisez ou vérifiez réellement pour vous assurer que le test réussit.
Sauf si vous avez une raison spécifique, un test doit être effectué dans les 5 secondes. Vérifiez tous les tests qui prennent beaucoup de temps en termes de temps d'exécution.
Les valeurs fixes telles que card_id = 1 sont des dettes techniques qui entraîneront une erreur si l'ID change à l'avenir. Pointez pour charger la valeur de test dans les appareils au lieu de la valeur fixe, ou pour extraire l'ID d'autres API de récupération de données.
Vérifiez dans quelle perspective le test est décrit. Après une longue période de fonctionnement, les membres seront remplacés, donc même si une erreur se produit dans le test, la raison ne sera pas claire.
Si vous écrivez un test distinct, par exemple, enregistrez-vous puis supprimez, une dépendance se produira. S'il existe une dépendance sur l'ordre d'exécution du test, une erreur se produira lors de la parallélisation du test pour accélérer, donc s'il y a une dépendance, indiquez qu'elle doit être combinée en une seule.
Recommended Posts