Software Testing

- kontrollierbarer Ersatz für eine vorhandene Abhängigkeit im System

- Code kann getestet werden, ohne die Abhängigkeit direkt handhaben zu müssen

- nachgeahmtes Objekt im System, das entscheidet, ob ein Unit Test funktioniert hat oder nicht

- verifiziert, ob das zu testende Objekt das Fake-Objekt wie erwartet aufgerufen hat

- Gewöhnlich gibt es nicht mehr als einen Mock pro Test

- Stelle im Code, in die man eine andere Funktionalität einfügen kann

- z.B. Stub Klasse, Konstruktor Parameter, Methode mit öffentlichem set, Delegate

- Injektion eines Fakes auf Konstruktor Ebene

- Injektion eines Fakes per Getter/Setter

- Injektion eines Fakes unmittelbar vor einem Methodenaufruf

Der Code Selber

• Funktionale Tests
    ▪ Von aussen sichtbare Ein-/Ausgabeverhalten
• Nicht funktionale Tests
    ▪ In welcher Qualität
• Anforderungsbezogener und strukturbezogener Test
    ▪ Kontrollfluss innerhalb von Komponenten
• Änderungsbezogener Test
    ▪ Softwarewartung und –pflege
    ▪ Testen nach Weiterentwicklung
    ▪ Regressionstest

- Prüfmethode, bei der das Testobjekt nicht mit Testdaten versehen oder ausgeführt wird

- Testobjekt wird mit Eingabedaten versehen und ausgeführt

- Es werden Tests Anhand der Spezifikation/Anforderung entwickelt

- die Tests werden ohne Kenntnisse über die innere Funktionsweise/Implementierung des zu testenden Systems entwickelt

- Es fliesst nur nach aussen sichtbares Verhalten in den Test ein

- Tests werden mit Kenntnissen über die innere Funktionsweise des zu testenden Systems entwickelt

- der Test wird am Code geprüft, da der Einblick auf den Quellcode gestattet ist

- Quellcodeteile mindestens einmal zur Ausführung bringen

Code ohne Tests

- Methode zur systematischen Bestimmung von testfällen

- Identifizierung von Ein- und Ausgabebedingungen

- zuerst alle Module/Komponenten entwickeln und erst dann das gesamte System auf einmal testen. (Testing beginnt sehr spät)

- Entwicklung beginnt beim Aufrufer z.B. UI

- alles, was noch nicht vorhanden ist, wird durch einen Stub ersetzt

- Entwicklung beginnt bei der aufrufbaren Komponente

- Aufrufer wird durch einen Treiber ersetzt

- Entwicklung kann in der Mitte beginnen, wenn die Aufrufer- und aufzurufenden Komponenten noch nicht entwickelt sind

- Anzahl Abhängigkeiten innerhalb der Komponenten (Wie viele Abhängigkeiten man aufbrechen muss, um die Klasse testen zu können)

Continuos Integration / Continuos Delivery

Für schnellers Feedback von automatisierten Tests um die Qualität der Software zu sichern.

Push zu VCS Version Control System (Git, usw)

Builden, Testen

Feedback bei Fehlschlag

Alles OK = Deployment

Ein Singleton ist ein Entwurfsmuster, das sicherstellt, dass eine Klasse nur eine einzige Instanz hat und einen globalen Zugriffspunkt darauf bietet. Es wird verwendet, um sicherzustellen, dass in einem System nur eine einzige Instanz einer Klasse existiert, was bei Ressourcen wie Datenbankverbindungen oder Loggern nützlich sein kann.

1. Testen zeigt die Anwesenheit von Fehlerzuständen
2. Vollständiges Testen ist nicht möglich
3. Frühes Testen spart Zeit und Geld
4. Häufung von Fehlerzuständen
5. Vorsicht vor dem Pestizid-Paradoxon
6. Testen ist kontextabhängig
7. Trugschluss: Keine Fehler bedeutet ein brauchbares System

Durch testing verringern sich die Risiken beim Einsatz der Software, da mögliche Fehler während des Testens aufgedeckt werden.

Fehlerwirkungen nachweisen
Qualität der Software bestimmen
Vertrauen in die Software zu erhöhen
Durch Analyse, Fehlerwirkungen vorbeugen

• Funktionalität
• Zuverlässigkeit
• Benutzbarkeit
• Effizienz
• Änderbarkeit
• Übertragbarkeit

Funktionalität

• Zuverlässigkeit
• Benutzbarkeit
• Effizienz
• Änderbarkeit
• Übertragbarkeit

• Eine Fehlhandlung (error) ist eine menschliche Handlung (etwa ein Schreibfehler eines Entwicklers), die zu einem falschen Ergebnis führt.

• Ein Fehlerzustand (defect) – auch Defekt – ist ein inkorrekter Teil eines Programmes oder Dokumentes, z.B. eine inkorrekte Anweisung oder Datendefinition, das die geforderte Funktion des Produkts beeinträchtigen kann.

• Eine Fehlerwirkung (failure) ist die Wirkung eines Fehlerzustandes, die bei der Ausführung des Testobjekts nach «aussen» in Erscheinung tritt, d.h. die Abweichung einer Komponente oder eines Systems von der erwarteten Lieferung, Leistung oder dem Ergebnis.

• Fehlermaskierung: Ein vorhandener Fehlerzustand wird durch einen oder mehrere andere Fehlerzustände in anderen Teilen des Testobjekts kompensiert, so dass dieser Fehlerzustand keine Fehlerwirkung hervorruft.

Eine Unit of Work ist die Summe aller
Aktionen, die zwischen dem Aufruf einer
öffentlichen Methode innerhalb eines Systems
und einem erkennbaren Endresultat beim Test
dieses Systems stattfinden

SUT steht für «System Under Test», manche
verwenden auch den Begriff CUT («Class Under
Test» oder «Code Under Test»). Wenn Sie etwas
testen, bezeichnen Sie das, was Sie testen, als
das SUT.

• Er sollte automatisiert und wiederholbar sein.
• Er sollte einfach zu implementieren sein.
• Einmal geschrieben, sollte er auch morgen noch relevant sein.
• Jeder sollte in der Lage sein, den Test auf einen Knopfdruck hin laufen zu lassen.
• Er sollte schnell ablaufen.
• Die Resultate sollten konsistent sein (die Tests geben immer den gleichen Wertzurück, wenn zwischen den Testläufen nichts  geändert wird).
• Er sollte die volle Kontrolle über die getestete Unit haben.
• Er sollte komplett isoliert sein (er läuft völlig unabhängig von anderen Tests).
• Wenn er fehlschlägt, sollte es einfach zu erkennen sein, was erwartet wurde und wie das Problem lokalisiert werden kann.

Sind nicht schnell

Sind nicht konsistent

Beinhalten eine oder mehrere Abhängigkeiten der zu testenden Unit.

Integrationstests erhöhen das Risiko für ein anderes
Problem: das Testen zu vieler Dinge auf einmal.

Properties sind gute Beispiele für Code, der
gewöhnlich keine Logik enthält und somit nicht
eigens von den Tests adressiert werden muss. Es
handelt sich um Code, der wahrscheinlich von einer
Unit of Work, die Sie testen, verwendet wird. Es
besteht daher keine Notwendigkeit, ihn direkt zu
testen. Aber seien Sie auf der Hut: Sobald Sie
irgendeine Überprüfung in eine Property einbauen,
sollten Sie sicherstellen, dass die Logik getestet
wird.

Eine Informationsquelle, ob die Ausgabe eines Programms(oder einer Funktion/Methode) korrekt ist oder nicht

- ein Programm

- eine Dokumentation

- ein dokumentierter Algorithmus

- ein menschlicher Domänenexperte

- eine Art zu sagen, dass die Ausgabe korrekt ist

- lokalisieren und beheben eines Defektes

- Fehlerbereinigung/Fehlerkorrektur

- Defekte bzw. Fehlerzustände lokalisieren
 

UnitOfWork_Szenario_ExpectedResult

Das testen, der funktionalen Einzelteile von Programmen auf ihre korrekte Funktionalität

- wird fast immer mithilfe eines UT Frameworks erstellt

- einfach zu schreiben und schnell in der Ausführung

- vertrauenswürdig, lesbar und wartbar

- konsistente Ergebnisse, solange Produktionscode nicht geändert wird

1. Zuverlässigkeit

2. Effizienz

3. Änderbarkeit

- Planung und Steuerung

- Analyse und Design

- Realisierung und Durchführung

- Auswertung und Bericht

- Abschluss