This commit is contained in:
David Schirrmeister 2025-04-07 13:03:46 +02:00
parent 7f0daca4b8
commit fef45678dc
2 changed files with 38 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

View File

@ -0,0 +1,38 @@
# 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
![image_555.png](image_555.png)
### 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](01_ImplementingForMaintainability.md#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](01_ImplementingForMaintainability.md#black-box-testing) hat gegensätzliche Vor-/Nachteile
> Black-/White-Box-Testing sind Konzepte, die auf verschiedene Test-Typen angewendet werden können
##