Skip to content

VM Tracker Client - Unit Tests

Übersicht

Dieses Projekt enthält umfassende Unit Tests für den VM Tracker Client, geschrieben in Go.

Test-Abdeckung

Aktuelle Coverage: 27.7% der Statements (fokussiert auf testbare Business-Logik)

Detaillierte Coverage nach Funktion:

Funktion Coverage Beschreibung
getHostname 60.0% Tests für Hostname-Erkennung
getIPAddress 81.8% Tests für IP-Adress-Erkennung
Post (DefaultHTTPClient) 100.0% HTTP Client Wrapper
sendRegistrationWithClient 83.3% Registration-Logik mit Mock HTTP Client

Hinweis: Die main() Funktion (0% Coverage) wird nicht getestet, da sie Orchestrierungslogik enthält, die besser durch Integrationstests abgedeckt wird.

Test-Kategorien

1. JSON Marshaling/Unmarshaling Tests

  • TestVMInfoJSONMarshaling: Testet die korrekte Serialisierung und Deserialisierung von VMInfo
  • Deckt normale Fälle, leere Felder und Sonderzeichen ab
  • Stellt sicher, dass JSON-Tags korrekt funktionieren

2. Hostname-Tests

  • TestGetHostname: Validiert die Hostname-Erkennung
  • Überprüft, dass ein gültiger Hostname zurückgegeben wird

3. IP-Adress-Tests

  • TestGetIPAddress: Umfassende Tests für Netzwerk-Interface-Erkennung
  • Gültige Interface-Namen
  • Ungültige Interface-Namen
  • Leere Interface-Namen
  • Validiert IPv4-Format
  • Erkennt automatisch verfügbare Netzwerk-Interfaces

4. HTTP Registration Tests

  • TestSendRegistrationSuccess: Erfolgreiche Registration
  • TestSendRegistrationHTTPErrors: HTTP-Fehler-Szenarien
  • 400 Bad Request
  • 401 Unauthorized
  • 404 Not Found
  • 500 Internal Server Error
  • 503 Service Unavailable
  • Netzwerkverbindungsfehler
  • TestSendRegistrationURLFormatting: URL-Formatierung
  • URLs mit/ohne Trailing Slash
  • URLs mit Port
  • HTTPS URLs
  • Localhost

5. Edge Cases & Validierung

  • TestVMInfoFieldValidation: Feldvalidierung
  • Sehr lange Hostnamen (255 Zeichen)
  • IPv6-mapped IPv4 Adressen
  • Komplexe Interface-Namen
  • TestDefaultHTTPClient: HTTP Client Wrapper

Benchmarks

Performance-Tests für kritische Operationen:

BenchmarkVMInfoMarshaling-8         11367013           110.8 ns/op        80 B/op          1 allocs/op
BenchmarkVMInfoUnmarshaling-8        1992078           606.0 ns/op       296 B/op          8 allocs/op

Interpretation: - Marshaling: ~111 ns pro Operation, sehr effizient - Unmarshaling: ~606 ns pro Operation, akzeptabel für JSON-Parsing - Geringe Memory-Allokationen

Tests ausführen

Alle Tests ausführen:

go test -v

Tests mit Coverage:

go test -v -cover

Detaillierter Coverage-Report:

go test -coverprofile=coverage.out
go tool cover -func=coverage.out

HTML Coverage-Visualisierung:

go test -coverprofile=coverage.out
go tool cover -html=coverage.out -o coverage.html
# Öffnen Sie coverage.html in einem Browser

Benchmarks ausführen:

go test -bench=. -benchmem

Spezifische Tests ausführen:

# Nur JSON-Tests
go test -v -run TestVMInfoJSON

# Nur IP-Adress-Tests
go test -v -run TestGetIPAddress

# Nur HTTP-Tests
go test -v -run TestSendRegistration

Mock-Architektur

Die Tests verwenden eine Mock-basierte Architektur für HTTP-Calls:

HTTPClient Interface

type HTTPClient interface {
    Post(url, contentType string, body *bytes.Buffer) (*http.Response, error)
}

Vorteile:

  • ✅ Keine echten Netzwerk-Calls in Tests
  • ✅ Volle Kontrolle über HTTP-Responses
  • ✅ Tests sind schnell und deterministisch
  • ✅ Einfaches Testen von Fehlerszenarien
  • ✅ Keine externen Abhängigkeiten

Code-Änderungen für Testbarkeit

Die main.go wurde minimal refactored:

  1. HTTPClient Interface: Ermöglicht Mocking von HTTP-Calls
  2. DefaultHTTPClient: Produktions-Implementation
  3. sendRegistrationWithClient: Testbare Version mit dependency injection
  4. sendRegistration: Wrapper für Produktionscode (unveränderte API)

Diese Änderungen: - ✅ Brechen keine bestehende Funktionalität - ✅ Sind rückwärtskompatibel - ✅ Ermöglichen umfassende Tests ohne echte Netzwerk-Calls

Best Practices

Die Tests folgen Go-Best-Practices:

  1. Table-Driven Tests: Mehrere Test-Cases in einer Test-Funktion
  2. Subtests: Strukturierte Organisation mit t.Run()
  3. Clear Naming: Deskriptive Test- und Subtest-Namen
  4. Mocking: Interface-basiertes Mocking für externe Abhängigkeiten
  5. Error Checking: Umfassende Fehlerbehandlung
  6. Benchmarking: Performance-Messungen für kritische Pfade

Continuous Integration

Diese Tests können einfach in CI/CD-Pipelines integriert werden:

# Beispiel GitHub Actions
- name: Run tests
  run: go test -v -coverprofile=coverage.out

- name: Upload coverage
  run: go tool cover -html=coverage.out -o coverage.html

Zukünftige Erweiterungen

Mögliche Test-Erweiterungen:

  • [ ] Integration-Tests für die gesamte main()-Funktion
  • [ ] Tests für Signal-Handling (SIGTERM, SIGINT)
  • [ ] Tests für Retry-Logik
  • [ ] Tests für Ticker-basierte Updates
  • [ ] Mock-Server für End-to-End-Tests
  • [ ] Property-based Tests mit fuzzing

Fehlerbehebung

Tests schlagen fehl mit "no valid network interface"

  • Dies ist normal, wenn keine nicht-Loopback IPv4-Interfaces verfügbar sind
  • Der Test wird automatisch übersprungen (t.Skip())

Coverage scheint niedrig

  • Die 27.7% Coverage konzentriert sich auf Business-Logik
  • main() und Orchestrierung sind absichtlich nicht getestet
  • Diese sind besser durch Integration-Tests abgedeckt

Kontakt

Bei Fragen oder Problemen mit den Tests, bitte Issue erstellen.