Als Entwickler mit JavaScript-Hintergrund habe ich ziemlich viel Zeit damit verbracht, Tests mit Jest zu schreiben. In meinem Projekt gimme_readme musste ich aufgrund der von mir verwendeten NPM-Module von Drittanbietern mit einigen experimentellen Funktionen von Node und Jest herumspielen. Ich konnte tolle Stack Overflow-Threads finden, die mir beigebracht haben, wie man Jest-Tests unter Verwendung der ES6-Syntax ausführt. Sagen wir einfach, ohne die Weisheit dieser klugen Menschen hätte ich Schwierigkeiten gehabt! Mit diesem Wissen über die Verwendung der experimentellen Funktionen von Jest war ich jedoch in der Lage:
Der Code für die CI-Pipeline, die ich oben beschrieben habe, ist hier zu finden und wird so eingestellt, dass er immer dann ausgeführt wird, wenn ein Push an einen beliebigen Zweig erfolgt oder wenn eine Pull-Anfrage vorliegt. Auf diese Weise weiß jeder, der versucht, zu meinem Repository beizutragen, ob der von ihm beigesteuerte Code „gut genug ist, um ihn in meinen Hauptzweig einzufügen“ – zumindest was automatisierte Tests betrifft.
Wie auch immer, das ist genug von der Arbeit, die ich damals für mein Repository geleistet habe.
Diese Woche habe ich beschlossen, die Herausforderung anzunehmen und einige Tests für ein Python-Projekt zu schreiben, das von meinem Freund Aryan Khurana geschrieben wurde. Aryans Projekt ist ein Befehlszeilentool namens github-echo, das Einblicke in ein GitHub-Repository bietet. Die Verwendung einer unbekannten Sprache und eines Testframeworks, das ich noch nie verwendet hatte (PyTest), lag definitiv außerhalb meiner Komfortzone, aber ich habe es sehr geschätzt, dass Aryan bereit war, mir die Grundlagen zu zeigen (danke Aryan!).
Als ich anfing, an Tests für das Repository von Aryan zu arbeiten, war ich sofort überwältigt davon, wie unterschiedlich die Tests aussahen. Während Jest für mich zu einem vertrauten Gebiet geworden war, fühlte sich Pythons Pytest sehr fremd an. Dennoch begann ich mit Aryans Anleitung und einiger Entschlossenheit, seine einzigartigen Eigenschaften zu verstehen.
Lassen Sie uns aufschlüsseln, was ich in ihren Testfällen entdeckt habe:
Parameterisiertes Testen: Eines der ersten Dinge, die mir ins Auge fielen, war der @pytest.mark.parametrize Decorator. Dies ähnelt test.each von Jest, jedoch mit einer saubereren Syntax:
@pytest.mark.parametrize( 'invalid_url', [ 'https://gitlab.com/username/repository', 'https://github.com/username', # ... more test cases ], )
Kontextmanager: Anstelle von Jests Expect().toThrow() verwendet Python Kontextmanager mit pytest.raises:
@pytest.mark.parametrize( 'invalid_url', [ 'https://gitlab.com/username/repository', 'https://github.com/username', # ... more test cases ], )
Temporäres Dateisystem: Die Tests verwenden das tmp_path-Fixture von pytest für Dateisystemoperationen, was viel sauberer ist als das Einrichten von Scheindateisystemen in Jest:
with pytest.raises(typer.BadParameter, match='Invalid GitHub repository URL'): check_cli_arguments(invalid_url, 'gemini', 0.5, Path('output.md'))
Diese Erfahrung in der Arbeit mit JavaScript- und Python-Testframeworks hat meine Sicht auf Softwaretests erweitert. Während sich Jest wie ein Heimatland fühlte, habe ich die leistungsstarken Funktionen von Pytest wie parametrisierte Tests und Fixtures zu schätzen gelernt. Unabhängig davon, ob Sie JavaScript- oder Python-Tests schreiben, das Endziel bleibt dasselbe: Ihren Benutzern zuverlässigen, gut getesteten Code bereitzustellen.
Das obige ist der detaillierte Inhalt von# Vom Scherz zum Pytest: Die Reise eines JavaScript-Entwicklers zum Python-Testen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!