Unit Testing in Autoit

Da muss ich mich quasi ausklammern
Ich baue selber normalerweise keine Units, erst recht nicht komplett universell. Dafür ist der Anwendungsbereich hier immer viel zu speziell.

Hmm, ich war bei UDF, vielleicht bin ich noch nicht ganz wach XD

Unit Test ist eigentlich ein muss.
Ein "aus dem Kopf übersetztes" Zitat: Nicht getesteter Code ist per Definition fehlerhaft.

Darum: Absolut interessant.

Zitat von BananaJoe

Ein "aus dem Kopf übersetztes" Zitat: Nicht getesteter Code ist per Definition fehlerhaft.

Und was hat das mit Unit Tests zu tun?

Wenn ich eine Funktion schreibe, dann hat die einen Sinn und Zweck! "Getestet" wird (bei mir zumindest) während der Entwicklung. Und zwar so, dass (für mich) alle denkbaren Zustände behandelt werden. Was nicht heißt, dass es nicht irgendwann während des späteren Einsatzes der Funktion doch zu Fehlern kommen kann! Dann wird genau dieser "Fehler" behoben und weiter gehts....

Unit Tests helfen da KEIN STÜCK! Denn Unit Tests sind nicht dafür da, die absolute Fehlerfreiheit zu garantieren! Die Unit Tests sind dazu da, die vorgegebenen Fälle und Rahmenbedingungen einer Funktion auf deren richtige Ausführung abzuklopfen, auch wenn die Funktion irgendwann verändert oder erweitert wird.

Und da liegt der Hase im Pfeffer! Wer diese Vorgaben und Rahmenbedingungen einer Funktion oder eines Programms nie oder nur selten verändert, der braucht auch keine Unit Tests.

Jeder von uns hat schon einmal eine Funktion verändert oder "verbessert" und nach dem Hieb auf F5 eine Fehlermeldung bekommen! Man vergisst, gerade bei umfangreichen Funktionen, welche Querverweise und Abhängigkeiten innerhalb des Codes bestehen. Der Unit Test findet den "Fehler" nicht, da die vom Programmautor vorgegebenen Ergebnisse

alle "richtig" sind. Bis auf die Fälle, die der Programmautor nicht bedacht hat..... Naja, dann wird eben für genau diesen Fall der Unit Test erweitert bzw. angepasst.

Für mich machen Unit Tests Sinn in professionellem Umfeld, wo ein hauptberuflicher Unit Test Programmierer die Arbeit seiner Kollegen veriifizieren muss. Dabei wird "natürlich" jeder denkbare mögliche und unmögliche "Fehler" versucht abzufangen. Wird der Code dann geändert und die Testumgebung meldet "Funktion arbeitet wie vorgegeben", dann ist die Chance hoch, dass das Programm auch nach diversen Änderungen "fehlerfrei" funktioniert....so lange bis ein "unerwarteter" Fehler auftritt....

Ich bin ziemlich sicher dass "professionelle" Unit Tester das obere Ende der Fahnenstange in der Programmiererzunft sind. Denn dass eine Funktion innerhalb ihrer Vorgaben ein "richtiges" Ergebnis hervorbringt ist dessen Aufgabe! Spannend wird es erst dann, wenn durch unvorhersehbare und vom Programmierer nicht beachtete Zustände ein "Fehler" gefunden werden muss.

Ich muss immer schon grinsen, wenn ein Kollege mich mit den Worten anruft "...hast du mal 10 Minuten Zeit, mein Programm läuft nicht und ich weiß nicht warum...". Debuggen von anderer Leute Code ist eine meiner Lieblingsbeschäftigungen. Das schult die Analytik und die fördert die Kommunikation. Gleichzeitig unterstützt es die eigene Kreativität, weil man sieht, wie andere Leute ein Problem programmtechnisch angehen! Unit Tests killen meinen Spass

Zitat von Andy

Für mich machen Unit Tests Sinn in professionellem Umfeld ...

In meiner Firma war das so: Basierend auf einer Risikoanalyse hinsichtlich Vertraulichkeit, Verfügbarkeit, Integrität etc. wurde ein möglicher (maximaler) Schaden ermittelt. Darauf aufbauend wurde dann entscheiden, wie das Risiko zu behandeln ist.
Dazu gibt es dann einen ganzen Blumenstrauß an Maßnahmen aus denen man wählen kann.
Klingt weniger nach Spass als nach mühsamer Arbeit

Die Schwierigkeit beim Testen sehe ich in der Auswahl der richtigen Testmethode, der Testfälle sowie der Testdaten.
Es ist wie beim Programmieren. Sind die Vorgaben (Lastenheft, Design etc.) schlecht, dann kann der Code auch nur schlecht sein. Garbage in, Garbage out

ich würde sagen, solange wir hier Code produzieren, der uns nicht durch Haftung (Softwarefirma, wobei die das meist auch ausschließen ) in Gefahr bringt finanziellen Schaden zu nehmen, sehe ich auch nicht die Notwendigkeit eines "extra" Unit-testings.

Und wie schon erwähnt wurde.
Solange es kein Pflichtenheft gibt, ist die Spielwiese eines Code Editors doch unser Königreich.

Ich würde mich da jetzt eher Andy anschließen.

Und meinen Code teste ich ja auch.
Und wenn sich einer beschwert, halte ich es wie Microsoft und schiebe bei Gelegenheit einen "fix" nach.

Zitat von water

Die Schwierigkeit beim Testen sehe ich in der Auswahl der richtigen Testmethode, der Testfälle sowie der Testdaten.

yepp, genau das meinte ich mit

Zitat von Andy

Ich bin ziemlich sicher dass "professionelle" Unit Tester das obere Ende der Fahnenstange in der Programmiererzunft sind.

Ich sehe die "Unit" als BlackBox, einzig interessant ist was reingeht, und was letztendlich raus kommen soll. Dafür eine Testumgebung zu schreiben ist manchmal sicherlich Aufwendiger wie die Funktion selbst!

Zitat von water

Garbage in, Garbage out

Hehe, THIS ! Wenn man Code lesen kann wie ein Buch und während des Lesens die Funktion des Codes (ggf. noch anhand der Kommentare) verstehen kann, dann ist das eine Offenbarung! Alles andere ist programmierter Bullshit. Kein Wunder, wenn "große" Softwareprojekte komplett neu geschrieben werden statt sie zu debuggen oder zu verbessern. Das liegt einfach daran dass die Programmierer ihren Job beim ersten Mal nicht richtig gemacht haben,

Zitat von Schnuffel

Und wenn sich einer beschwert, **SNIP nicht nur Microsoft^^ *** schiebe ich bei Gelegenheit einen "fix" nach.

Ich sehe darin nicht das Problem! Das Problem ist den "Fix" gar nicht nachschieben zu können, weil man tausende Zeilen Müll produziert hat, in dem keine Sau mehr durchblickt!

Und hier schließt sich der Kreis. Denn Unit Tests nützen hier nichts! Wäre der "Bug" im Vorfeld aufgefallen, hätte ihn der Programmierer oder spätestens der Unit Tester bemerkt!

Ich lehne mich mal weit aus dem Fenster mit einer Behauptung: "Schreibe gut wartbaren Code und du kannst dir alle Unit Tests sparen!"

Zitat von Schnuffel

Solange es kein Pflichtenheft gibt, ist die Spielwiese eines Code Editors doch unser Königreich.

...und genau deswegen werden immer neue Programmiersprachen und esoterische Paradigmen entwickelt...weil kaum einer seinen Job "richtig" macht....weil es sowohl an der Qualifikation hängt, als auch an den Vorgaben:

Zitat von water

Sind die Vorgaben (Lastenheft, Design etc.) schlecht, dann kann der Code auch nur schlecht sein

Und von "richtig machen Wollen" ist hier nicht mal die Rede!

Der Hauptpunkt ist meiner Meinung nach einfach die Projektgroesse.

Fuer ein kleineres Projekt sind Unit Tests ein recht grosser Aufwand zu einem recht kleinen nutzen, weil es uebersichtlich genug ist, um manuell zu testen.

Wenn ein Projekt richtig gross ist, mit millionen Zeilen an Code, dann werden sie nicht nur zum testen genutzt, sondern teilweise auch zum entwickeln. Es ist einfach ein riesiger Aufwand, die Funktionen in der Gesamtumgebung zu entwickeln, wenn das compilieren+starten der Anwendung mehrere Minuten dauert und es sehr viele unterschiedliche Variablen gibt, die einem da rein pfuschen koennen (unzaehlige verschiedene Parameter, die alle getestet werden muessen). Da werden die Unittests nach der Spezifikation geschrieben, was passieren soll und mit denen entwickelt man dann seinen Code. Wenn dann alles soweit funktioniert, wird der branch nach code review gemerged und der neue Code wird ueber Nacht in die Hauptcodebase eingefuegt und mit dem gesamt System getestet (natuerlich auch mit Unittests).

In dem Fall muss man also sowieso die Tests schreiben, einfach nur um beim entwickeln den eigenen Code mal laufen zu lassen, ohne dass jedesmal ne Menge Zeit drauf geht; Von Aenderungen (auch durch Kollegen, die den Code vorher noch nicht gesehen haben) mal ganz abgesehen.

Von daher ist mein Anspruch: Unittests sobald das Projekt gross genug ist oder der Code oefter geaendert werden soll. Ausserdem gibts immer Unittests fuer alle Schnittstellen nach aussen, um Sicherzustellen, dass dort nicht ausversehen irgendwas uebersehen wird und das dann ne Sicherheitsluecke darstellt (Stichwort Rest-API,... mit ner Menge an Funktionen nach aussen; ein Berechtigungscheck vergessen und jeder kann Daten abfragen; Sowas darf nicht passieren).

Naja Grundsätzlich teste ich Code auf diverse Weise.

Bei Funktionen (oder auch Units :P) kommt es bei mir auf den Anwendungsfall an, da:

- Ich mir die Funktionen step by Step zusammenbaue mit vielen Entwicklungsschritten und damit auch vielen Zwischentests um zu prüfen ob das jeweilig erwartete Ergebnis heraus kommt.
- es meißt viele Abhängigkeiten außerhalb des eigentlichen Skriptes gibt, wo ich auf Test-PC's arbeite aber somit oft nicht nur die Unit/Funktion prüfen muss, sondern das gesamte bis dahin erstellte Skript.

"Echte" Unit-Tests würde ich behaupten mache ich nur, wenn ich einen Ausgangsstring angeben kann der dann in Ergebnis X umgewandelt werden muss. Bei allem anderen eher wie oben beschrieben.