Re: [Python-de] Fehler vor Ausführung finden
Am 27.01.2019 um 19:44 schrieb Christopher Arndt:
Am 27.01.19 um 18:57 schrieb Michael S.:
Heute wieder einmal einen Fehler entdeckt, wo ich von "self.State" gelesen habe, statt von "State". "self.State" gab es gar nicht, wird nirgends angelegt und nie verwendet. Das war einfach falsch runtergeschrieben.
Diesen Fehler hätte z.B. "pylint" gefunden:
Soo, nach vielen Stunden ... Dem Raspberry habe ich schon seit Jahren kein Update mehr gegönnt, never Touch a running Heizung ... Deshalb lies sich pylint darauf nicht installieren, ohne dass ich vorher Updates fahre, was ich aber definitiv auf den Sommer schieben möchte. Also ein 2015er Lubuntu aus der VirtualBox hervorgekramt und versucht, pylint, da zu installieren. Fehlanzeige, System nicht aktuell. Allerdings auch zu alt, um ein Upgrade auf ein 2018er Lubuntu zu machen. Deshalb ne neue virtuelle Maschine aufgesetzt und aktuelles Lubuntu installiert. Darauf dann pylint und das Code-Verzeichnis des Raspberrys. pylint Main.py -> tausende Meldungen pylint Main.py -E -> nix Das dann mit allen eingebundenen py-Files einzeln gemacht und tatsächlich ist noch ein Fehler aufgetaucht. Kann man pylint auch sagen, dass es sich da selbst durchhangeln soll und alle Files, die importet sind, mitscannt? Michael
On 27/01/2019 23.10, Michael S. wrote:
Am 27.01.2019 um 19:44 schrieb Christopher Arndt:
Am 27.01.19 um 18:57 schrieb Michael S.: Deshalb ne neue virtuelle Maschine aufgesetzt und aktuelles Lubuntu installiert. Darauf dann pylint und das Code-Verzeichnis des Raspberrys.
pylint Main.py -> tausende Meldungen pylint Main.py -E -> nix
Das dann mit allen eingebundenen py-Files einzeln gemacht und tatsächlich ist noch ein Fehler aufgetaucht.
Kann man pylint auch sagen, dass es sich da selbst durchhangeln soll und alle Files, die importet sind, mitscannt?
Das weiß ich nicht, aber du kannst statt eines einzelnen Moduls ein Package angeben, in der Praxis also ein Verzeichnis. Pylint hier möchte eine `__init__.py` in dem Verzeichnis, kennt in der Hinsicht also keine Namespace Packages (PEP 420). Viele Grüße Stefan
Nun, eine Syntaxprüfung allein ist nur ein Placebo, denn über das Verhalten von Funktionen erfährt man so nichts. Zu Qualitätssicherung sollte man testgetrieben entwickeln. Die trifft übrigens auf alle Programmiersprachen zu. Hierfür greift man am besten auf Testframeworks zurück, um das Verhalten aller Funktionen zu testen. Bei Unittest wird nicht nur das Verhalten auf gültige Eingabewerte geprüft, sondern auch die Fehlerverarbeitung mit mit ungültigen Werten. Siehe: https://wiki.python.org/moin/PyUnit Startet man diese Unittest bei jedem Entwicklungsschritt, erkennt man auch schnell Seiteneffekte: Änderung in Funktion A() ändert Verhalten von Funktion B(). Gruß Raymond Am 27.01.19 um 23:10 schrieb Michael S.:
Am 27.01.2019 um 19:44 schrieb Christopher Arndt:
Am 27.01.19 um 18:57 schrieb Michael S.:
Heute wieder einmal einen Fehler entdeckt, wo ich von "self.State" gelesen habe, statt von "State". "self.State" gab es gar nicht, wird nirgends angelegt und nie verwendet. Das war einfach falsch runtergeschrieben.
Diesen Fehler hätte z.B. "pylint" gefunden:
Soo, nach vielen Stunden ... Dem Raspberry habe ich schon seit Jahren kein Update mehr gegönnt, never Touch a running Heizung ... Deshalb lies sich pylint darauf nicht installieren, ohne dass ich vorher Updates fahre, was ich aber definitiv auf den Sommer schieben möchte.
Also ein 2015er Lubuntu aus der VirtualBox hervorgekramt und versucht, pylint, da zu installieren. Fehlanzeige, System nicht aktuell. Allerdings auch zu alt, um ein Upgrade auf ein 2018er Lubuntu zu machen.
Deshalb ne neue virtuelle Maschine aufgesetzt und aktuelles Lubuntu installiert. Darauf dann pylint und das Code-Verzeichnis des Raspberrys.
pylint Main.py -> tausende Meldungen pylint Main.py -E -> nix
Das dann mit allen eingebundenen py-Files einzeln gemacht und tatsächlich ist noch ein Fehler aufgetaucht.
Kann man pylint auch sagen, dass es sich da selbst durchhangeln soll und alle Files, die importet sind, mitscannt?
Michael
On 01/05/2019 20.58, Raymond Czerny wrote:
Zu Qualitätssicherung sollte man testgetrieben entwickeln. Die trifft übrigens auf alle Programmiersprachen zu.
Ich finde testgetriebene Entwicklung vor allem dann sinnvoll, wenn man schon genau weiß, wo man hin will. Wenn ich noch mit dem Design experimentiere und Dinge noch während der Entwicklung hin- und herschiebe, schreibe ich noch keine Tests für diesen Code. Ich schreibe die Tests dann aber, wenn sich das Design einigermaßen stabilisiert hat. Ein Kompromiss ist unter Umständen, auch schon während einer solchen Design-Phase ein paar "High-Level-Tests", also eher Integrationstests zu schreiben, so dass man wenigstens ein bisschen Qualitätskontrolle hat.
Bei Unittest wird nicht nur das Verhalten auf gültige Eingabewerte geprüft, sondern auch die Fehlerverarbeitung mit mit ungültigen Werten.
Wichtiger Hinweis, ja. :-) In dem Zusammenhang ist auch interessant, wenn es keine "falschen" Werte für einzelne Argumente gibt, sondern ein Fehler durch bestimmte Argument-Kombinationen zustandekommt. In dem Fall sollte man möglichst versuchen, das Design zu vereinfachen, so dass es möglichst keine "Querabhängigkeiten" zwischen Argumenten gibt bzw. sie unabhängig voneinander getestet werden können. Viele Grüße Stefan
participants (3)
-
Michael S. -
Raymond Czerny -
Stefan Schwarzer