Codingtagebuch

Der Kurs nutzt häufig input() – etwas, das ich bisher selten eingesetzt habe. Auch type() will ich künftig bewusster zum Testen nutzen.

Ich habe festgestellt, dass ich früher zu oft float-Werte für Bedingungen verwendet habe. Das will ich ändern, da Floats speicherbedingt ungenau sein können. Stattdessen plane ich, häufiger mit bool-Werten zu arbeiten.

Den Operator % nutze ich schon – er hilft z. B. beim Überprüfen von Aktualisierungen.

Im Kurs wird das Tool „Thonny“ vorgestellt, das Schritt-für-Schritt-Debugging ermöglicht. Ich halte es für hilfreich bei kleineren Tests oder unklaren Ausgaben – besonders bei Problemen, die sich durch print- oder .txt-Ausgaben schwer nachvollziehen lassen.

In komplexeren Projekten bevorzuge ich Logging mit Beispielausgaben, um Veränderungen gezielt zu prüfen.

Die Bibliothek random enthält Funktionen wie random.choice(), die ich bisher kaum verwendet habe – aber sehr nützlich finde.

range() werde ich künftig bewusster einsetzen, da es für viele Iterationen passender ist als Listen.

f-Strings sind für mich ein Gamechanger – einfacher und lesbarer als frühere String-Formate.

Bei Schleifen setze ich eher auf for und eine einzige while-Schleife, um Kontrollverlust zu vermeiden.

Ich finde es hilfreich, Variablen, die im Projekt mehrfach geändert werden können, zentral am Anfang der Datei zu definieren. Das erhöht Übersichtlichkeit und Verständlichkeit.

Bei komplexeren Abläufen werde ich künftig mit draw.io Entscheidungsbäume visualisieren, um Logik leichter nachvollziehen zu können.

Bisherige „dauerhaft laufende“ Skripte habe ich mit try / except / finally und Neustart-Logik gebaut, ohne Fehlerarten zu unterscheiden – künftig will ich spezifische Fehler (z. B. ValueError) gezielt loggen.

Beim Testen eines Snake-Spiels, das mit der turtle-Bibliothek in Python umgesetzt wurde, fiel auf: Die zufällig erzeugte Position des „Food“-Objekts war oft leicht versetzt zum Raster der Schlange. Das erschwerte das visuelle Erfassen – die Schlange konnte das Futter zwar technisch erreichen, jedoch nicht exakt mittig treffen.

Ursache war die bisherige Koordinatenlogik:

              random_x = random.randint(-280, 280)
              random_y = random.randint(-280, 280)

Diese ließ beliebige Koordinaten zu – auch Werte wie (175, 123), obwohl sich die Schlange nur in 20er-Schritten über das Spielfeld bewegt.

Die Lösung bestand darin, die zufällige Platzierung des Futters an das Grid der Schlange anzupassen. Statt pixelgenauer Koordinaten wird nun innerhalb des Spielfelds gezielt auf 20er-Stellen multipliziert:

              random_x = random.randint(-14, 14) * 20
              random_y = random.randint(-14, 14) * 20

Ergebnis: Futter und Snake bewegen sich nun synchron auf demselben Raster. Die Positionierung wirkt aufgeräumt und das Spielerlebnis ist deutlich intuitiver.

Diese kleine Anpassung ist ein gutes Beispiel für das Zusammenspiel von visuellem Feingefühl und koordinatenbasierter Logik – und zeigt, wie sich mit wenigen Zeilen Code ein klarer Mehrwert für den User erzielen lässt.

In der Softwareentwicklung unterscheidet man verschiedene Arten von Tests, um Qualität und Funktionalität sicherzustellen:

• Smoke-Test: Ein Smoke-Test stellt bspw. sicher, dass die Webseite fehlerfrei im Browser geöffnet werden kann, ihre Navigation sichtbar ist und das Schließen des Browsers keine Fehler verursacht.
• Unit-Test: Test einzelner Funktionen oder Methoden isoliert vom Gesamtsystem.
• Integrationstest: Prüft das Zusammenspiel mehrerer Komponenten (z. B. Datenbank und API).
• Systemtest: Test eines vollständigen Ablaufs unter realistischen Bedingungen – z. B. das Ausfüllen und Absenden eines Formulars mit anschließender Weiterleitung auf eine Bestätigungsseite.
• Akzeptanztest: Prüfung, ob die Anwendung so funktioniert, wie es Nutzende oder Projektverantwortliche erwarten – etwa in Bezug auf Inhalte, Funktionen oder gesetzliche Anforderungen.
• Regressionstest: Sicherstellung, dass bestehende Funktionalität durch neue Änderungen nicht unbeabsichtigt beeinflusst wird.
• Explorativer Test: Testen ohne vorher festgelegte Abläufe, bei dem die Anwendung gezielt und kreativ erkundet wird – mit dem Ziel, Fehler und unerwartetes Verhalten aufzudecken.
• Performanztest: Überprüfung der Ladezeit, CPU-Auslastung und Rendering-Zeiten, z. B. mit Google Lighthouse.
• Kompatibilitätstest: Sicherstellen, dass die Webseite in verschiedenen Browsern und auf verschiedenen Geräten konsistent dargestellt wird.

Ein Smoke-Test stellt sicher, dass grundlegende Funktionen der Webseite bereitstehen. Beispielsweise:

• Öffnet sich die Webseite korrekt?
• Ist ein zentrales Navigationselement wie „Überblick“ im Seiteninhalt sichtbar?

              
                *** Settings ***
                Library    SeleniumLibrary

                *** Variables ***
                ${URL}    https://www.lukas-kauzmann.com

                *** Test Cases ***
                Google Öffnet Erfolgreich
                    Open Browser    ${URL}    chrome
                    Wait Until Page Contains    Überblick    5s
                    Close Browser
              
            

Der Akzeptanztest prüft, ob rechtliche Anforderungen im Impressum eingehalten werden:

• Sind Pflichtparagraphen wie § 5 TMG und §18 Abs. 2 MStV enthalten?
• Sind die erforderlichen Angaben im sichtbaren Text enthalten?

              
                *** Settings ***
                #Library    BuiltIn
                Library    SeleniumLibrary

                *** Variables ***
                ${URL}    https://www.lukas-kauzmann.com/impressum.html

                *** Test Cases ***
                Impressum Enthält Pflichtangaben
                    Open Browser    ${URL}    chrome
                    Maximize Browser Window

                    # Warte auf das Impressums-Element
                    Wait Until Element Is Visible    xpath=//section[contains(@class, "impressum-section")]    5s

                    ${text}=    Get Text    xpath=//section[contains(@class, "impressum-section")]
                    Log    >>> GEFUNDENER TEXT <<<\n${text}
                    Log To Console    >>> GEFUNDENER TEXT <<<\n${text}

                    #${count}=    Evaluate    text.count("§")    text=${text}
                    #${count}=    Convert To Integer    ${count}
                    #${count}=    Evaluate    """${page}.count('§')"""

                    # Workaround: schreibe Text in temporäre Datei, dann zähle in Python
                    ${count}=    Evaluate    __import__('re').findall("§", """${text}""").__len__()

                    IF    $count < 2
                        Fail    Es wurden nur ${count} Paragraphenzeichen gefunden
                    END

                    # Prüfen auf wichtige Nummern
                    Should Contain    ${text}    5
                    Should Contain    ${text}    18

                    # Check auf "Absatz" oder "Abs."
                    ${result_abs}=    Run Keyword And Ignore Error    Should Contain    ${text}    Absatz
                    ${result_abs2}=   Run Keyword And Ignore Error    Should Contain    ${text}    Abs.

                    IF    '${result_abs[0]}' != 'PASS' and '${result_abs2[0]}' != 'PASS'
                        Fail    Absatz/Abs. fehlt
                    END

                    # Check auf "TMG" oder "Telemediengesetz"
                    ${result_tmg}=    Run Keyword And Ignore Error    Should Contain    ${text}    TMG
                    ${result_tmg2}=   Run Keyword And Ignore Error    Should Contain    ${text}    Telemediengesetz

                    IF    '${result_tmg[0]}' != 'PASS' and '${result_tmg2[0]}' != 'PASS'
                        Fail    TMG fehlt
                    END

                    # Check auf "MStV" oder "Medienstaatsvertrag"
                    ${result_mstv}=    Run Keyword And Ignore Error    Should Contain    ${text}    MStV
                    ${result_mstv2}=   Run Keyword And Ignore Error    Should Contain    ${text}    Medienstaatsvertrag

                    IF    '${result_mstv[0]}' != 'PASS' and '${result_mstv2[0]}' != 'PASS'
                        Fail    MStV fehlt
                    END

                    Log    Impressum enthält alle wichtigen Paragraphen

                    Close Browser
              
            

Der Systemtest bezieht sich auf das Kontaktformular:

• Eingabefelder werden korrekt angezeigt und validiert
• Die Formulardaten werden korrekt übermittelt
• Die Bestätigungsseite enthält korrekt dargestellte Sonderzeichen (z. B. „ü“)
• Der "Zurück zur Startseite"-Link funktioniert

              
                *** Settings ***
                Library    SeleniumLibrary

                *** Variables ***
                ${URL}    https://www.lukas-kauzmann.com

                *** Test Cases ***
                Kontaktformular Funktioniert und Bestätigungsseite Zeigt Umlaute
                    Open Browser    ${URL}/impressum.html    chrome
                    Maximize Browser Window

                    Wait Until Element Is Visible    id=name    5s

                    # Formular ausfüllen
                    Input Text    id=name      Jürgen Mustermann
                    Input Text    id=email     "E-Mail-Adresse"
                    Input Text    id=message   Dies ist ein Test mit einem Umlaut: ü

                    Scroll Element Into View    xpath=//button[@type='submit']
                    Click Button    xpath=//button[@type='submit']

                    # Warte auf Weiterleitung zur Danke-Seite
                    Wait Until Location Contains    danke.html    5s

                    # Prüfe, ob das "ü" korrekt angezeigt wird
                    Page Should Contain    ü

                    # Zurück zur Startseite navigieren (wenn ein Button oder Link vorhanden ist)
                    Click Link    Zurück zur Startseite

                    # Prüfen, ob Startseite erreicht wurde
                    Wait Until Page Contains    Überblick    5s

                    Log    Kontaktformular und Weiterleitung funktionieren einwandfrei

                    Close Browser
              
            

Während der Testentwicklung sind mir einige typische Herausforderungen begegnet, die ich durch gezielte Workarounds lösen konnte:

• Probleme bei der Textauswertung mit Evaluate: Beim Zählen von Paragraphenzeichen („§“) im Impressum wurde trotz sichtbarer Inhalte mehrfach der Wert 0 zurückgegeben. Die Ursache lag darin, dass nicht der gesamte sichtbare Text korrekt übergeben wurde. Durch präzise Auswahl der richtigen xpath-Section und zusätzliche Ausgabe des Textes in der Konsole konnte ich verifizieren, dass die richtigen Inhalte abgegriffen wurden. Zunächst ließ sich die Anzahl der Paragraphenzeichen (‚§‘) im Text nicht zuverlässig zählen – weder mit einfachen Zählbefehlen noch durch direkte Übergabe des Textes an Evaluate. Deshalb wurde ein Workaround genutzt: Der Textinhalt wurde in eine temporäre Python-Umgebung übergeben, in der ein regulärer Ausdruck (also ein Suchmuster für bestimmte Zeichen) eingesetzt wurde, um alle Vorkommen von „§“ zu zählen – unabhängig von Zeilenumbrüchen oder Formatierungen. So konnte der Inhalt korrekt und robust überprüft werden.
• Kombinierte Bedingungen mit Evaluate: Mehrfachversuche, Bedingungen wie "Absatz" in text or "Abs." in text direkt per Evaluate auszuwerten, führten zu Syntaxfehlern – vor allem bei größeren Texten mit Sonderzeichen. Stattdessen wurde ein robusterer Ansatz gewählt: mit Run Keyword And Ignore Error wurde für beide Varianten geprüft, ob ein Begriff enthalten ist. Die Ergebnisse wurden dann mit einem IF-Block interpretiert.
• Timing-Probleme beim Seitenaufbau: Gerade bei Weiterleitungen oder dynamischem Laden von Inhalten (z. B. nach dem Absenden des Kontaktformulars) trat das Problem auf, dass der Test zu schnell weiterlief. Durch gezielte Verwendung von Wait Until Element Is Visible bzw. Wait Until Page Contains konnte sichergestellt werden, dass erst geprüft wird, wenn die Seite vollständig bereit ist.
• Fehler beim Klick auf Buttons (ChromeDriver): In einem Fall wurde beim Klick auf den Submit-Button ein ElementClickInterceptedException ausgelöst. Ursache war, dass der Button noch außerhalb des Viewports lag. Die Lösung bestand darin, das Element vorher per Scroll Element Into View sichtbar zu machen, um es danach zuverlässig klicken zu können.

Diese Herausforderungen haben mir gezeigt, dass auch einfache Tests durch technische Details beeinflusst werden können – und mir erneut vor Augen geführt, wie wichtig es ist, strukturiert zu debuggen und flexibel zu reagieren.

Zur Verbesserung der Performance, Barrierefreiheit und Suchmaschinenoptimierung habe ich gezielte Tests mit Google Lighthouse durchgeführt.

Die Ergebnisse wurden systematisch analysiert und schrittweise umgesetzt – mit dem Ziel, technische Schwachstellen zu beseitigen und Best Practices zu etablieren.

• Entfernung des initialen Page-Loaders, der zu Ladeproblemen führte
• Einführung eines dezenten fade-in-Effekts zur Verbesserung der UX ohne Render-Blockierung
• Ersetzung klassischer Bildformate durch moderne WebP-Dateien mit JPEG-Fallback
• Skalierung der Bildgrößen passend zur tatsächlichen Darstellung im Frontend (z. B. 400 × 400 px)
• Integration von preconnect für externe Ressourcen wie Google Fonts und CDN-Links
• Validierung und technische Korrektur der canonical-Tags mittels Weiterleitung via .htaccess
• Minifizierung von CSS-Dateien zur Reduktion der Ladezeit (kein Einsatz von PurgeCSS, da essenzielle Klassen entfernt wurden)

Ein bestehendes Warnsignal zum Thema eval()-Verwendung wurde bewusst nicht behandelt, da Lighthouse lediglich den Einsatz bestimmter Methoden wie setTimeout("code") beanstandet – nicht aber sichere Varianten mit Funktionen (wie bei dieser Seite).

Der empfohlene Ansatz bei der Nutzung von Lighthouse: Zuerst die roten Probleme (kritische Fehler) beheben, anschließend gezielt gelbe Hinweise (Optimierungspotenziale) angehen. Die grauen Tipps sind optional, aber oft hilfreich für langfristige Wartbarkeit oder UX-Aspekte.

Das aktuelle Ergebnis: 100 Punkte im Bereich SEO – bei stabiler, semantisch klarer Umsetzung und guter Nutzerführung.

Um die Darstellung und Bedienbarkeit auf verschiedenen Endgeräten zu überprüfen, habe ich manuelle Kompatibilitätstests durchgeführt. Ziel war es, visuelle Inkonsistenzen und Abweichungen im responsiven Verhalten zu identifizieren.

Getestete Kombinationen:

• Safari (Mac, WQHD-Auflösung)
• Chrome (Mac & mobil simuliert via DevTools)
• Chrome (Android Smartphone)
• Responsively App zur simultanen Geräteansicht (iPhone, iPad, Mac)

Beobachtungen:

• Index.html (Safari, Mac): Links neben den Icons erscheinen bei der Animation feine Linien, die in anderen Browsern nicht auftreten – vermutlich rendering-spezifisch für Safari.
• Profilbild: In iPhone- und iPad-Ansicht wird das runde Bild sichtbar oval verzerrt – besonders deutlich auf iPad-Bildschirmgrößen.
• Navigation (mobil): Der Link „Codingtagebuch“ springt bei kleinen Viewports als einziger in die zweite Zeile der Navigation – hier wäre ein kleiner Layout-Fix sinnvoll.
• Projekte.html (mobil): Auf Smartphones verschwinden die leichten horizontalen Versätze zwischen Projekten. Dadurch wirken Titel und Videos etwas gestaucht, die Abstände zu den Folgetiteln sind sehr knapp.
• Codingtagebuch.html (mobil): Das eingebundene Lighthouse-Bild bei den Performanztests ist auf kleinen Displays schwer lesbar. Ein Zoom- oder Lightbox-Mechanismus könnte hier Abhilfe schaffen.
• Kontaktformular: Der Funktionstest auf mobilen Geräten wurde vorerst ausgelassen und wird ggf. separat nachgeholt.

Fazit: Die Webseite ist auf allen getesteten Geräten funktional und weitgehend responsiv. Einzelne Darstellungsdetails wie runde Bilder, Abstände bei Mobilansicht oder Safari-spezifische Artefakte sollten in künftigen Optimierungsrunden angepasst werden.