Unit Testing in Autoit

  • Hi liebe Leute 👋 ,

    heute bringe ich euch mal ein etwas "schwierigeres Thema" mit 🤭 - testing - genauer gesagt Unit Testing in AutoIt. Ich bin mir recht sicher, dass das Thema nicht intellektuell schwierig zu erfassen ist (keineswegs) sondern als Entwickler wird sich i. d. R. einfach stark beim Thema Testing zurückgehalten 😅 .

    In diesem Beispiel möchte ich einfach eine mögliche Verwendung von Unit Tests aufzeigen sowie die Vorteile dazu beleuchten und die Fragestellung klären, wann ein Unit Test angebracht wäre (sinnvoll ist) und wann er ggf. einfach unnötiger ist.

    => Ich bin schon sehr gespannt was ihr meint und ob ihr jemals Unit Tests eingesetzt habt 🤔 ?
    => Jemals in AutoIt? Oder generell mal? Lasst uns in den Austausch gehen #BinNeugierig .

    ---------------------

    ⚠ Disclaimer: Die folgende Video-Reihe hat den Zweck (Bildungszweck), des aufbauens und teilen von Wissen. Es dient in keinster Weise dem Autor (mir) in Bezug auf Youtube, Wachstum des Kanals oder einer Monetarisierung. Falls dies als Nebenprodukt entstehen sollte, ist dies unabhängig von der Intension des Bildungszweckes hier.

    🎬 Unit Testing in AutoIt

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    ⌚ Kapitel:
    00:00 Einleitung
    01:08 Code Struktur (includes)
    02:00 Erläuterung des Programmablaufs
    03:50 Erklärung der Beispielfunktionen
    08:07 Manueller Tests
    09:35 Unit Test: Erste Variante
    11:14 Unit Test: Data Driven Testing

    📑 Inhalt:
    Kurzvorstellung wie Unit Tests in AutoIt geschrieben werden können.
    Auch der Aspekt wann es sinnvoll ist diese zu schreiben, wird erläutert.

    🎪 Zielgruppe:
    Für AutoIt-User und Interessierte, die im Thema Testing deutlich tiefer einsteigen möchten
    als sie es bisher getan haben. Zudem mit der Fragestellung sich beschäftigen, ob sich das Programm
    wirklich korrekt verhält, so wie man es erwartet.

    🔇 Out of scope:
    Ich habe bewusst auf komplexere Unit Test Strukturen verzichtet.
    Ebenfalls habe ich die Abgrenzung zu Integrationstests nicht erläutert.

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    ⌚ Kapitel:
    00:00 Einleitung
    00:20 Unit Test: Aufbau Data Driven Testing
    04:24 Unit Test: Data Driven Loop
    06:19 Unit Test: Tests laufen lassen
    06:57 Unit Test: Fehler entdeckt, super
    08:34 Unit Test: einfach erweitern
    10:11 Fragestellung und Fazit
    11:38 Beispiel eines unsinnigen Unit Tests
    14:39 Zusammenfassung
    15:14 Schreibt mich an

    📑 Inhalt:
    Kurzvorstellung wie Unit Tests in AutoIt geschrieben werden können.
    Auch der Aspekt wann es sinnvoll ist diese zu schreiben, wird erläutert.

    🎪 Zielgruppe:
    Für AutoIt-User und Interessierte, die im Thema Testing deutlich tiefer einsteigen möchten
    als sie es bisher getan haben. Zudem mit der Fragestellung sich beschäftigen, ob sich das Programm
    wirklich korrekt verhält, so wie man es erwartet.

    🔇 Out of scope:
    Ich habe bewusst auf komplexere Unit Test Strukturen verzichtet.
    Ebenfalls habe ich die Abgrenzung zu Integrationstests nicht erläutert.


    💡 Eindrücke/Feedback ist natürlich erwünscht, Danke 🤝 .

    Viele Grüße
    Sven

    Nachtrag: Die Quellen im Video verwendet, findet ihr hier.

  • 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.

  • [...] Dafür ist der Anwendungsbereich hier immer viel zu speziell.

    Danke für dein Beitrag Moombas , allerdings verstehe ich das Argument oder die Aussage nicht. Also inhaltlich weiß ich nicht was du damit meinst 🤔 ?

    Ich baue selber normalerweise keine Units [...]

    Du schreibst doch Funktionen die ganze Zeit, diese würde man als Units betiteln bspw. 😅 .

    Viele Grüße
    Sven

  • :rofl: ... no worries Moombas.

    Gehe dennoch davon aus, dass du bisher nie Unit Tests geschrieben hast oder?
    Soll keine Bewertung darstellen, mich interessiert nur, ob dies für dich - respektive für viele - relevant ist oder nicht.
    Mal abgesehen von der Fragestellung ob es überhaupt bekannt 😅 .

    Schönen Abend noch, bin bald offline.

  • 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. :Glaskugel: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:rofl:

  • 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. :rofl:

    MfG Schnuffel

    "Sarkasmus ist die niedrigste Form des Witzes, aber die höchste Form der Intelligenz."
    Val McDermid

    ein paar Infos ...

    Wer mehr als "nur" Hilfe benötigt, kann sich gern im Forum "Programmieranfragen" an uns wenden. Wir helfen in allen Fällen, die die Forenregeln zulassen.

    Für schnelle Hilfe benötigen wir ein ! lauffähiges ! Script, dass wir als Demonstration des Problems testen können. Wer von uns erwartet ein Teilscript erstmal lauffähig zu bekommen, der hat
    1. keine wirkliche Not
    2. keinen Respekt vor Menschen die ihm in ihrer Freizeit Ihre Hilfe anbieten
    3. oder ist einfach nur faul und meint wir coden das für ihn

    In solchen Fällen erlaube ich mir, die Anfrage einfach zu ignorieren. ;)

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

    yepp, genau das meinte ich mit

    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!

    Garbage in, Garbage out :)

    Hehe, THIS :thumbup:! 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,

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

    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!"

    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:

    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).

  • Ich wollte mit diesem Thread keinen Glaubenskrieg oder ähnliches auslösen. Am Ende seid ihr alle erfahren genug um die für euch richtige Methode heraus zu picken, eure UDFs, Skripte, Programme nachherzu fehlerfrei zu entwickeln.

    Wie im Video auch mehrfach erwähnt, ging es mir in erster Linie um die Vorstellung und Vorteile von Unit Tests (auch für AutoIt). Das diese Testkategorie neben Integrationstests, Systemtests, UI-Tests und vielen weiteren keine absolute Sicherheit bietet, steht außer Frage.

    Danke aber für die Interessante Diskussion 👌 .

    Viele Grüße

    Sven

  • 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.

  • Unit Tests entwickeln ihre Vorteile, wenn viele Entwickler an noch mehr Units gemeinsam arbeiten.
    Solche Anwendung werden automatisch gebaut.
    Der Automat, der das tut, führt alle Unit Tests immer wieder aus.
    Misslingt ein Unit Test, dann bekommt der Entwickler, der für das Unit zuständig ist einen "Einlauf" bzw. wird benachrichtigt, dass er nachbessern muss.
    Kollaboratives Arbeiten in großen Teams wäre ohne Unit Tests nicht möglich.
    Werden später Fehler gefunden (die es immer geben wird) wird der Fehler gefixt, aber auch die Liste der Unit Tests erweitert um einen Test der belegt, dass der Fehler gefixt wurde.
    Zum Beispiel bei dem Problem der Seiteneffekte, entfalten automatisierte Unit Tests ihre positive Wirkung, dann schlagen Unit Tests fehl, die vor einer Code Änderung gelaufen sind.

    In dem Bereich in dem ich gerade unterwegs bin (Medizinforschung) geht ohne Software Validierung mit Unit Tests garnichts.
    Hier ein Tool (https://testanything.org/), was ich auch im Datenbank Umfeld schon eingesetzt habe.

    PS: da gibt es noch den Test before Ansatz, das ist ein separates Thema, was hier zu weit führt.

    So und jetzt Schluss mit der Klugscheißerei.

  • ich bin grad an selbst an massig Units xD produzieren... -> und momentan ist alles ein Test :D ich nenne das einfach bisher immer Funktionen.

    -> möchte für autoit units erstellen die es erleichtern große guis zu erstellen ohne viel Code und tamtam und mit der option ob feste gui oder flexible gui.

    -> ich war gestern zu 50 % gefühlt fertig mit den Grundfunktionen dann wollte ich noch etwas anderes rein implementieren und seit dem hab ich massig Fehler produziert ~.~ und nun drück ich mich etwas davor xD aber ich werde es bald weitermachen....

    also für mich sind Funktionen essentiel.

  • Danke sodinoel und danke MojoeB 🤝 .

    MojoB: Nutzt du eine Versionsverwaltung wie Git bspw.? Denn was du beschreibst lässt sich mit Git recht einfach vermeiden. Also Änderungen nochmal einsehen und nachvollziehen was ggf. das Problem sein kann. Meist einfacher als sich durch diverse Code-Stellen einzeln durchzudebuggen.

    Bald wird es übrigens für VSCode einen richtigen AutoIt-Debugger (javascript based) geben, mit dem man wie in den meisten anderen Sprachen seine Anwendung ordentlich debuggen kann. Die üblichen die wir derzeit haben (direkt mit AutoIt geschrieben), haben mich nie überzeugt um ehrlich zu sein.
    Aber dies nur als Randnotiz 😅 .

    Viele Grüße
    Sven

  • SOLVE-SMART

    nein durch dich habe ich bereits auf vscode umgestellt, während der Umstellung habe ich isn studio weiter genutzt und anfangs nur wenig mit vs code gearbeitet.
    durch die weitere Nutzung python habe ich mich dann an vs code angefreundet.
    git hatte ich kurz daheim drauf, aber ist schon wieder unten, einer der gründe war das ich das nicht auf der Arbeit nicht nutzen kann.

    die Autoit Erweiterungen funktionieren bei mir auch nicht zu 100% wieso kann ich dir nicht sagen.
    ich bin froh das ich Skripte über vs code mit f5 starten kann.

    Ansonsten wollte ich eh umstellen auf meinem Unraid Server habe ich ein Docker VS Code web Applikation gefunden darüber wollte ich zukünftig entwickeln.
    ich habe momentan Schwierigkeiten mit meiner Hardware deshalb stockt das etwas.

    Bloß für autoit wird das nichts bringen da es kein Windows ist. ^^

    irgendwann werde ich auch git wieder installieren und richtig nutzen aber momentan war es für mich nicht auf meiner prio liste.

  • Danke dir MojoeB für die Erläuterung. Verstehe ... .
    Ich drücke die Daumen das du bald wieder mit GIT in Berührung kommst, denn es macht die Entwicklung so viel besserer/sicherer in gewisser Hinsicht.

    Bis später dann.

    Viele Grüße
    Sven