Eine Geschichte über einen Gehaltsingenieur, der für ein Unternehmen arbeitet, das keine Testcode-Kultur hat und hart daran arbeitet, die Testkultur zu verbreiten, während er nach dem Teint des Managers fragt. Am Ende des Artikels schreibe ich den Standpunkt, wenn der Code den Test überprüft.
"Dies ist ein Release-First-Projekt. Die Idee, Testcode als Team in einem Wort vom Manager zu schreiben, wurde abgelehnt. Ich konnte verstehen, warum ich nicht auf Abenteuer gehen sollte, weil ich nicht das Know-how habe, um Testcode intern zu schreiben. Es sollte jedoch in Ordnung sein, in meiner Freizeit einen Test zu schreiben, also habe ich beschlossen, mein Bestes zu geben.
Als ich einen Ingenieur fragte, von dem ich wusste, gab es ungefähr zwei Leute, die einen Test geschrieben hatten. Ich werde es ihm nicht sagen, aber er wird als Mentor zertifiziert sein und Ihnen effiziente Methoden und Know-how mit Python und Django beibringen. Rückblickend denke ich, dass ich mit der Umwelt gesegnet war. Angenommen Pytest, das mehrere Testrahmen für Python hat, aber eine solide offizielle Dokumentation hat. Pytest ist sehr funktional und die Dokumentation ist kompliziert. Ich denke, Sie können lernen, wie man es mit Beispielen verwendet und es als Wörterbuch verwendet.
Installieren Sie pytest
pip install pytest
pytest Testprobe
# -*- coding: utf-8 -*-
from __future__ import absolute_import, unicode_literals
#Funktion zum Testen
def add(a, b):
return a + b
#Testcode Funktionsname ist Test_Wie fange ich mit pytest an?
def test_add():
assert add(1, 1) == 2
assert add(1, 2) != 2
Ausführungsergebnis des Pytests
>>> $ 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 =============================================================================
Zuerst habe ich hart gearbeitet, um einen Unit-Test zu schreiben, aber es scheint, dass die Belastung für den Entwickler hoch ist. Es gibt das Gefühl, sich zu sehr anzustrengen. Als ich ihn konsultierte, riet er mir, einen Black-Box-Test auf Web-API-Basis anstelle eines funktionsbasierten Tests auf einem Soshage-Server durchzuführen. Als ich es ausprobierte, war der Entwicklungsaufwand gering und einfach und leistungsstark. Ich benutze es immer noch. Die Codeabdeckung wurde nicht verbessert, aber Web-API-Tests können die API mit weniger Aufwand abdecken.
Diese Testmethode ist besonders nützlich in Skriptsprachen, in denen häufig Fehler gefunden werden, die beim Kompilieren erkannt werden.
Pytest-Code zum Testen der Web-API im JSON-Stil
# -*- coding: utf-8 -*-
from __future__ import absolute_import, unicode_literals
import ujson
import requests
def test_api():
#Testen Sie die GitHub-API
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)
#Der HTTP-Statuscode lautet 200
assert response.status_code == 200
#In der Lage sein, BODY mit json zu analysieren
data = ujson.loads(response.text)
#URL im Array, state, created_Die Existenz des Elements von at
for param in data:
assert 'url' in param
assert 'state' in param
assert 'created_at' in param
pytest Ausführungsergebnis
>>> $ 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 =============================================================================
Als alle API-Tests des Servers abgeschlossen waren, haben wir eine Regel festgelegt, die im Team konsultiert und der Web-API-Test geschrieben werden soll. Da pytest über einen einfachen Mechanismus verfügt, kann ihn jeder mit Beispielcode leicht erlernen. Es dauert jedoch lange, schlammige Arbeiten auszuführen, z. B. in der Überprüfung darauf hinzuweisen, bis sie behoben ist, regelmäßig Tests durchzuführen, Fehler zu beheben und neue Teilnehmer zu informieren. (Wenn Sie damit vertraut sind, führen Sie es regelmäßig aus? Ich glaube, Sie hatten das Gefühl, dass es sich um einen automatischen Test mit Commit-Hook handelt. Zu dieser Zeit dachte ich darüber nach, es einzuführen, aber ich habe vergessen, es einzuführen, ohne schwer zu werden. )
-Ermöglicht das Ausführen aller Tests mit einem Befehl (von der Shell geschrieben) ・ Um uns bequem zu entwickeln, haben wir darauf geachtet, alle Tests innerhalb von 60 Sekunden abzuschließen. ・ Es wurde beschlossen, dass der Test die Arbeitsabschlussbedingung im Bauverfahren für die lokale Umgebung erfüllt. ・ Bestätigt, dass der Test während der Codeüberprüfung bestanden wurde ・ Bei der Entwicklung einer neuen Funktion ist es Voraussetzung, dass zum Zeitpunkt der Codeüberprüfung ein Test angehängt wird. ・ Ich habe regelmäßig einen Test durchgeführt und ihn reparieren oder reparieren lassen.
Die App wurde erfolgreich veröffentlicht und eine Testkultur setzte sich im Team durch. Die Entwicklung erfolgt auf Pull-Request-Basis, wobei der Testcode angehängt wird, ohne darauf hinzuweisen. Aufgrund des Testfehlers stellten wir eine Abhängigkeit zwischen dem neu entwickelten Modul und dem Modul fest, von der angenommen wurde, dass sie außerhalb des Einflussbereichs liegt, und konnten den Produktionsfehler verhindern.
In der Checkliste zum Zeitpunkt der Bereitstellung wird in der Regel immer klar angegeben, dass die Testausführung durchgeführt wird, sodass die Gewohnheit, Tests bereits in der Entwicklungsphase auszuführen, bei den Mitgliedern Wurzeln geschlagen hat.
Ich proklamierte, dass es gut wäre, eine interne Lernsitzung abzuhalten und einen Test zu schreiben. Der Grund für den Erfolg unseres Projekts war, dass wir Testcode geschrieben haben. Besonders in der Firma war es effektiv, weil ich den tatsächlichen Testcode teilen konnte.
Es ist ein Test der Zeit, und wenn Sie ihn über einen längeren Zeitraum weiter betreiben, trägt der Testcode technische Schulden. Ein problematischer untergeordneter Test, der bei jeder Änderung korrigiert werden muss, ein Test, dessen einmalige Ausführung mehr als 300 Sekunden dauert, und ein Testcode, der auskommentiert wird, weil ein Fehler aufgrund eines Problems mit dem Testcode selbst bei der Bereitstellung in Eile aufgetreten ist. Testen Sie den Code, der zu kompliziert ist, um ihn zu reparieren, und Sie wissen nicht, was Sie testen.
Seit Beginn der Operation ist ein Jahr vergangen. Tests, die ursprünglich in weniger als 60 Sekunden abgeschlossen wurden, dauern jetzt 12 Minuten. Die Regel zum Ausführen des Tests bei der Bereitstellung wird aufgrund der Latenz ebenfalls weggelassen. Viele der Ingenieure waren Veteranen und das Debugging-Team war ausgezeichnet, sodass die Fehler nicht zunahmen. Viele Leute haben Tests für die neue Modul-Pull-Anfrage geschrieben, aber die Testkultur innerhalb des Projekts hat sich verschlechtert.
Aufgrund des Einflusses der internen Studiensitzung und der Tatsache, dass einige Ingenieure den Testcode bereits einzeln geschrieben hatten, obwohl ich beabsichtigte, selbst zu beginnen, steigt die Anzahl neuer Projekte, die das Testschreiben in der Regel schrittweise übernehmen. ging. Ich mache einen Test! Ich denke, es ist wichtig, das zu sagen.
Ende
Wenn Sie die Implementierung der Geschäftslogik vernachlässigen, funktioniert sie nicht gemäß den Spezifikationen. Daher ist es wichtig, sie zu implementieren. Sie ist jedoch auch dann gut, wenn Sie den Testcode nicht implementieren oder ausführen. Ich denke, der Grund, warum die Testkultur zurückgegangen ist, ist, dass das Entwicklungsteam von der Wartung des Tests erschöpft ist. Deshalb werde ich aufschreiben, wo er erschöpft war.
Ich denke, wir hätten Commit-Hook und Jenkins verknüpfen oder TravisCI oder CircleCI übernehmen und sie automatisch testen sollen, wenn sie festgeschrieben wurden. Ich habe in diesem Artikel über die Verwendung von CircleCI in Django geschrieben
Das Team war erschöpft von der Wartung des Tests, der kompliziert von den Stammdaten abhängt und aufgrund des Problems des Tests selbst alle zwei Male fehlschlägt. Ich denke, dass Tests mit schlechter Qualität wegen des Stoffwechsels weggeworfen und neu geschrieben werden sollten.
Ich kann nicht auf einen Test warten, der länger als 60 Sekunden dauert. Da das Entwicklungstempo langsam sein wird, sollten wir meiner Meinung nach mehr Überlegungen anstellen, damit wir uns bequem entwickeln können, indem wir die parallele Ausführung von Tests in Betracht ziehen und sie in zwei Ebenen wie Schnelltest und Volltest aufteilen.
Obwohl ein Fehler auftritt, wenn er über einen längeren Zeitraum betrieben wird, ist die Anzahl der Variablen in einer Reihe und die Person, die ihn geschrieben hat, weiß nicht, um welchen Test es sich handelt. Ich denke, es war.
Dies ist eine wirksame Maßnahme für neue Teilnehmer. Wenn Sie auch nach dem Bau prüfen, ob der Test für jede Pull-Anforderung bestanden wurde, wird er schnell behoben.
Wenn Sie mit der Entwicklung auf der Grundlage einer Pull-Anforderung fortfahren, ist die Steuerung effektiv, sodass Sie verhindern können, dass die Anzahl der nicht getesteten Codes zunimmt und der Bildungseffekt groß ist.
Wenn ein Testfehler auftritt, wird das Testergebnis niemand sehen, daher wird der Behebung des Testergebnisses Vorrang eingeräumt. Wenn jemand es auf Vollzeitbasis repariert, wird es sich nicht für immer verbessern, so dass es für die Ausbildung gut sein kann, wenn Sie es im Dienst herumtragen.
Wenn die Testausführungszeit langsam ist, können Sie die Ergebnisse nicht sehen. Daher sollten Sie Schritte unternehmen, um die Tests parallel auszuführen oder den Test zu beschleunigen.
Dies ist der Gesichtspunkt, um die Codeüberprüfung beim Empfang einer Pull-Anforderung zu überprüfen.
Automatisieren oder auschecken, um sicherzustellen, dass der Test erfolgreich ist.
Sofern Sie keinen bestimmten Grund haben, sollte ein Test innerhalb von 5 Sekunden abgeschlossen sein. Suchen Sie nach Tests, deren Ausführungszeit lange dauert.
Feste Werte wie card_id = 1 sind technische Schulden, die zu einem Fehler führen, wenn sich die ID in Zukunft ändert. Zeigen Sie entweder auf den Testwert in Fixtures anstelle des festen Werts oder ziehen Sie die ID aus anderen Datenabruf-APIs.
Überprüfen Sie, in welcher Perspektive der Test beschrieben wird. Nach einer langen Betriebszeit werden die Elemente ersetzt. Selbst wenn im Test ein Fehler auftritt, ist der Grund nicht klar.
Wenn Sie beispielsweise einen separaten Test schreiben, registrieren und dann löschen, tritt eine Abhängigkeit auf. Wenn eine Abhängigkeit von der Testausführungsreihenfolge besteht, tritt beim Parallelisieren des Tests zur Beschleunigung ein Fehler auf. Wenn also eine Abhängigkeit besteht, weisen Sie darauf hin, dass diese zu einer kombiniert werden sollte.
Recommended Posts