DavidS/zusammenfassungen

Fork 0

David Schirrmeister 4b3fdb97a3 update

2025-04-09 15:46:28 +02:00

14 KiB

Raw Blame History

Implementing for Maintainability

Motivation and Introduction

Unit und Integration Testing ist ein bekannter Ansatz um Qualität sicherzustellen
Gut-getestete Anwendungen:
- 1 line of code = 1-3 lines of test code
- kann auf bis zu 1:10 hochgehen
Produkt- und Testcode werden parallel geschrieben
guten Code schreiben ist schwer

Black-/White-Box Testing

Black-Box-Testing

Nur das Interface ist bekannt, nicht der Inhalt

Methode vom Software-Testing, das die Funktion analysiert, ohne den Mechanismus zu kennen
Normalerweise rund um die Spezifikationen und Anforderungen
- Was soll die Anwendung tun, nicht wie tut sie es

White-Box-Testing

Das Interface und alle Mechanismen sind bekannt

Testmethodik, die verifiziert, wie die Anwendung arbeitet
Tests sind am Sourcecode ausgerichtet, nicht an den Anforderungen

Pros / Cons

White-Box-Testing ist systematischer und anspruchsvoller
- Analyse des Codes kann zu Fehlerentdeckungen führen, die zuvor übersehen wurden
- Testergebnisse sind oft spröde
  - Sind sehr verknüpft mit der Implementierung des Codes
  - Solche Tests produzieren viele false-positives und sind nicht gut für die Metrik der Resistenz gegen Refactoring
- Können häufig nicht rückgeschlossen werden zu einem Verhalten, dass wichtig ist für eine Business-Person
  - Starkes Zeichen, dass die Tests nicht viel Wert hinzufügen
Black-Box-Testing hat gegensätzliche Vor-/Nachteile

Black-/White-Box-Testing sind Konzepte, die auf verschiedene Test-Typen angewendet werden können

Testing Quadrants Matrix

Quadrant 1: Technologie-fokussierte Tests, die das Development leiten

Developer Tests:
- Unit tests
  - Verifizieren Funktionalität eines kleinen Subsets des Systems
  - Unit Tests sind die essenzielle Basis einer guten Test-Suite
    - Verglichen mit anderen, sind sie einfach zu erstellen und warten
    - Viele Unit-Tests :)
- Component-/Integration Tests:
  - Verifizieren Verhalten eines größeren Teils
Tests sind nicht für den Kunden

Goals of Testing during Implementation

Aktiviere nachhaltiges Wachstum des Software-Projekts

Nachhaltigkeit ist wichtig
- Projektwachstum ist am Anfang einfach
- Das Wachstum zu halten ist schwer
Tests können das nachhaltige Wachstum fördern
- Aber: erfordern initialen, teilweise signifikanten Einsatz
Schlechte Tests bringen nichts
- verlangsamen am Anfang schlechten Code
- langfristig trotzdem ungünstig
Test Code ist Teil der Codebase
- Teil, der ein spezifisches Problem behandelt - Anwendungsrichtigkeit sicherstellen
Kosten eines Tests
- Wert
- anstehende Kosten
  - Refactoring des Tests, wenn der Code refactored wird
  - Test bei jeder Codeänderung ausführen
  - Mit Fehlalarmen durch den Test umgehen
  - Zeit für das Verstehen des Tests, wenn man den zu testenden Code verstehen möchte

General Testing Strategy

Testing Automation Pyramid

Software Tests in 3 Kategorien aufteilen
- UI-Tests
  - Testen die Anwendung durch Interaktion mit der UI
  - sehr high-level
- Service Tests
  - Black-Box testen von größeren Softwareteilen
    - bspw. Komponenten, Services
- Unit Tests
  - werden während Entwicklung von Developern geschrieben
Gibt Idee, wie viele Tests pro Kategorie in der Test-Suite sein sollten

Testing Ice Cream Cone

Style einer Test-Suite, die häufig in der Industrie verwendet wird
- hohe Anzahl manueller, high-level Tests
- end-to-end Tests (auch an UI), die automatisch ausgeführt werden können
- nur wenige integration/unit tests
Tests Suite mit dieser Strategie ist nicht gut wartbar
- manuelle Tests sind teuer und langwierig
- automatisierte high-level Tests gehen häufig kaputt, sobald Änderungen in der Anwendung auftreten

Test Driven Development (TDD)

Tests schreiben
- Design
  - Akzeptanzkriterien für den nächsten Arbeitsschritt festlegen
  - Anregung lose gekoppelte Komponenten zu entwerfen
    - einfache Testbarkeit, dann verbinden
  - Ausführbare Beschreibung von dem was der Code tut
- Implementierung
  - Vervollständigen einer regressiven Test-Suite
Tests ausführen
- Implementierung
  - Error erkennen, während der Kontext noch frisch ist
- Design
  - Bewusstmachung, wann die Implementierung vollständig ist

Golden Rule of TDD: schreibe niemals neue Funktionalitäten ohne einen fehlschlagenden Test

Vorteile des TDD

signifikante Reduktion der Defekt-Rate
- auf Kosten eines moderaten Anstiegs im initialen Development-Prozesses
Empirische Untersuchungen haben das noch nicht bestätigt
- TDD hat aber zu Qualitätssteigerung des Codes geführt

Häufige Fehler beim TDD

Individuelle Fehler
- Vergessen die Tests regelmäßig auszuführen
- Zu viele Tests auf einmal schreiben
- Zu große/grobe Tests schreiben
- zu triviale Tests schreiben, die eh funktionieren
Team-Fehler
- Nur partieller Einsatz
- Schlechte Wartung der Test-Suite
- Verlassene Test-Suite (nie ausgeführt)

Unit-Testing vs. Integration Testing

Unit	Integration
kleiner Teil eines Verhaltens	größere Portion Code

4 Typen von Produktions-Code

Dimensionen

Komplexität und Domain-Signifikanz

Code Komplexität
- Definiert durch Nummer der Branching-Punkte im Code
- if-statements, Polymorphismus
Domain-Signifikanz
- Wie signifikant ist der Code für die problematische Domain
- normalerweise Verbindung Domain-Layer-Code zu End-User-Ziele
  - Hohe Domain-Signifikanz
- Bsp. für niedrige Relevanz: Utility Code

Nummer der Kollaborateure

Kollaborateur = Abhängigkeit, die veränderlich /& außerhalb des Prozesses ist
- veränderlich
  - nicht nur read-only
- außerhalb des Prozesses
  - häufig geteilt
  - hindert Tests an unabhängiger Ausführung
Code mit vielen Kollaborateuren ist schwer zu testen

Typen

Domain model & algorithms

Domain Code, wenige Kollaborateure
komplexer Code häufig Teil des Domain-Models
wenige Kollaborateure → Testbarkeit
sollte NIEMALS Abhängigkeiten außerhalb des Prozesses haben

Controllers

Wenig Domain Code, viele Kollaborateure
Koordination der Ausführung von Use-Cases für Domain-Klassen und externen Anwendungen
Keine komplexe / Business-kritische Arbeit selbst/allein machen
wenig Komplexität, wenig Domain-Signifikanz
Viele Abhängigkeiten außerhalb des Projekts

Overcomplicated Code

Viel Domain Code, viele Kollaborateure
ist aber auch komplex und wichtig

Trivialer Code

wenig Domain-Code, wenig Kollaborateure

Separierung von Controllers & DomainModel, Algorithmen

Separiert komplexen Code von Code, der Orchestrierung macht
- Domain Code hat tiefe Implementierung in Business Logik
- Controller haben breite Orchestrierung aber enge Komplexität
Erhöht Wartbarkeit und Testbarkeit

Wie testet man die 4 Typen?

trivialer Code muss nicht getestet werden

Unit Testing

Beim Unit Testing gehts nicht nur um den technischen Aspekt
- möglichst wenig Zeit Input
- möglichst viel Benefits

Gute Test-Suite

integriert in SDLC
- Tests bringen nur was, wenn man sie ständig benutzt
  - am besten alle automatisiert bei jeder Änderung
testet nur die wichtigsten Teile der Code-Base
- Business-Logik
- Systemkritische Teile
  - auch Abhängigkeiten nach außen
- Rest nur indirekt / wenig testen
gibt maximalen Wert mit minimalem Wartungsaufwand
- Auch automatisierte Tests müssen ggf. nach Änderungen angepasst werden
  - Nur Tests behalten, die wirklich sinnvoll sind

Was ist ein Unit-Test

Verifiziert einen kleinen Teil des Codes (unit)

macht es schnell

macht es isoliert

London School Interpretation

Isolation bedeutet, dass jede Klasse ihren eigenen Test bekommt
- Auch wenn sie von gleicher Klasse erben

Testing Doubles

Objekt, dass gleiches Verhalten und Aussehen, wie Gegenstück hat
Vereinfachte Version, die Komplexität verringert

Vorteile London School Interpretation

Wenn ein Test fehlschlägt, ist klar, was kaputt ist
Gibt Fähigkeit den Objektgraphen aufzusplitten
- Jede Klasse hat ihre eigenen Abhängigkeiten / Vererbungen
- Schwer zu testen ohne Testing Doubles
- Es müssen nicht die Abhängigkeiten von Abhängigkeiten beachtet werden
  - haben ja eigene Tests
Projektweite Guideline:
- Nur eine Klasse auf einmal

Classic School Interpretation

Isolation bedeutet, dass jeder Test in Isolation läuft
- Mehrere Klassen auf einmal ist okay
  - Solange sie alle auf ihrem eigenen Speicher laufen
  - kein geteilter Zustand
- Verhindert Kommunikation /Beeinflussung zwischen Tests
  - Scheiß auf Reihenfolge oder Ergebnis von anderen Tests

Geteilte, private, Out-Of-Process Abhängigkeiten

Geteilte Abhängigkeiten
- Können sich gegenseitig beeinflussen
  - Müssen ersetzt werden
  - bspw. geteilte DB → neue/bearbeitete Daten können Tests beeinflussen
Private Abhängigkeiten → :)
Out-Of-Process Abhängigkeiten
- Meistens ähnlich wie geteilte Abh.
  - DB = geteilt und out-of-process
- read-only-DB ist fine
- also: kommt drauf an ob gut oder nicht

Beispiel Classic School

Enough inventory → purchase geht durch, inventory amount geht runter
not enough product → kein purchase, keine änderungen
Typische AAA-Sequenz
- arrange, act, assert
  - alle Abhängigkeiten und System vorbereiten
  - Verhalten ausführen, das verifiziert werden soll
  - Erwartete Ergebnisse überprüfen
Outcome:
- Customer und Store werden verifiziert, nicht nur Store
- Jeder Bug in Store lässt die Tests fehlschlagen
  - auch wenn Customer komplett richtig ist

Beispiel London School

Gleiche Tests, aber Store wird mit test-doubles ersetzt
- "fake dependency" = "Mock"
AAA Sequenz {id="aaa-sequenz"}
- Arrange:
  - Store nicht modifizieren, stattdessen festlegen, wie er auf hasEnoughInventory() reagieren soll
- Act
- Assert
  - Interaktion zwischen Store und Customer wird genauer untersucht

Vergleich Classic / London

	Isolation of	A unit is	Uses test doubles for
London School	Units	A class	All but immutable dependencies
Classic School	Unit tests	A class or a set of classes	shared dependencies

Unit Tests - Good Practices

Good Practices - Structuring

Offensichtliche Struktur ist wichtig
- Code wird häufiger gelesen als geschrieben
AAA-Pattern splittet Tests in 3 Teile
- Alternative: Give-When-Then Pattern
  - Einziger Unterschied: besser lesbar für nicht-Programmierer

Zu vermeidende Dinge

Manchmal benutzt ein Test mehrere AAA Steps
- bspw:
- ist kein Unit-Test mehr, sondern ein Integration-Test
if-statements
- wird schwerer lesbar
- sollte eine simple Sequenz ohne branches sein

Größe der AAA Sections

arrange
- meistens am größten
- falls deutlich größer als act und assert zusammen
  - extrahieren in neue Methode oder separate Factory-Klasse
act
- sollte nicht mehr als eine Zeile sein
assert
- kann mehrere Asserts beinhalten
  - eine unit kann ja auch mehrere Dinge verändern, die überprüft werden müssen
- zu viele asserts implizieren schlechten Production-Code
  - fehlende Abstraktion bspw.
teardown-Phase (alles wieder auf den alten Stand bringen)
- die meisten unit-Tests brauchen keine
- ist meistens durch ein anderes Modell gelöst
  - bspw. Mocks oder so

Good Practices - Naming Tests

aussagekräftige Namen
häufig aber schlecht:
- [MethodeDieGetestetWird][Szenario][ErwartetesErgebnis]
Name in plain Englisch besser lesbar
Beispiel
- Sum_TwoNumbers_ReturnsSum() :(
- Sum_of_two_numbers() :)

Guideline

Keiner starken Benennungspolicy folgen
Benenne die Tests als würdest du es einem nicht-Programmierer-Deppen erklären, der aber die Anwendung kennt
Separiere Wörter, sodass sie lesbar sind
- bspw. durch -, _, testTest

Good Practices - Parameterized Tests

Motivation:

Ein Test ist meistens nicht genug um eine Verhaltens-Unit zu beschreiben
- hat div. Komponenten

Beispiel:

Online-Store mit Lieferfunktion

constraint: frühstes Lieferdatum ist übermorgen

public void Delivery_with_a_past_date_is_invalid()
public void Delivery_for_today_is_invalid()
public void Delivery_for_tomorrow_is_invalid()
public void The_soonest_delivery_date_is_two_days_from_now()

das viel zu viel
wenn man das mal auf größere Probleme anwendet wirds nicht besser

Parametrisierte Tests: {id="parametrized-tests"}

gruppieren Tests
meiste xUnit Frameworks haben Funktion dafür
Beispiel in .NET:
Also:
- weniger Test-Code
- Aber:
  - schwerer herauszufinden, welche Fakten die Methode repräsentiert
  - je mehr Parameter, desto schwieriger

14 KiB Raw Blame History