Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m450:learningunits:lu15:umsetzung [2024/11/25 11:23] – [Basierend auf Unittests] msuter
+++ modul:m450:learningunits:lu15:umsetzung [2024/11/29 09:25] (aktuell) – msuter
@@ Zeile 6: / Zeile 6: @@
 ===== Big-Bang-Integration =====
-Bei dieser Strategie wird das Zusammenspiel aller Komponenten (Module, Funktionen, Klassen) gleichzeitig getestet.
+| {{:modul:m450:learningunits:lu15:bigbang.png?600|}} | Bei dieser Strategie wird das Zusammenspiel aller Komponenten (Module, Funktionen, Klassen) gleichzeitig getestet. Dabei verzichten wir vollständig auf Mocks. Anhand der Hauptsteuerung suchen wir die Hauptkomponenten unserer Applikation. Zu diesen Komponenten schreiben wir Integrationstests. Dabei werden alle Komponenten, die von den Hauptkomponenten angesprochen werden, automatisch auch getestet. |
-Dabei verzichten wir vollständig auf Mocks.
-Anhand der Hauptsteuerung suchen wir die Hauptkomponenten unserer Applikation.
-Zu diesen Komponenten schreiben wir Integrationstests.
-Dabei werden alle Komponenten, die von den Hauptkomponenten angesprochen werden, automatisch auch getestet.
 ===== Top-Down-Integration =====
-Im Gegensatz zur Big-Bang-Integration testen wir immer nur eine Schicht auf einmal.
+| {{:modul:m450:learningunits:lu15:topdown.png?600|}} | Im Gegensatz zur Big-Bang-Integration testen wir immer nur eine Schicht auf einmal. \\ Wir starten mit der höchsten Ebene der Anwendung, z. B. der Hauptsteuerung oder den GUI-Komponenten, und arbeiten uns schrittweise zu den unteren Schichten (z. B. Datenbankzugriff oder Services) vor. Mocks werden hier häufig eingesetzt, um noch nicht integrierte Unterschichten zu simulieren. |
+==== Erste Schicht ====
+  - Wähle eine Komponente (nennen wir sie **function_F**) aus, die von der Hauptsteuerung aufgerufen wird.
+  - Erstelle eine Testfunktion bei der die Hauptsteuerung die **function_F** aufruft.
+  - Erstelle simulierte Funktionen für **B** und **C** (Mocks).
+  - Führe die Tests aus: Dokumentiere dabei auftretende Fehler und behebe diese iterativ.
+Wiederhole diese Schritte, bis die erste Schicht **F, G, H** vollständig getestet ist.
+==== Weitere Schichten ====
+In weiteren Testfällen prüfen wir nun die Komponenten, welche von der Komponente **F** aufgerufen werden.
+Dies wird nun Komponente für Komponente und Schicht für Sicht wiederholt.
-Wir starten mit der höchsten Ebene der Anwendung, z. B. der Hauptsteuerung oder den GUI-Komponenten, und arbeiten uns schrittweise zu den unteren Schichten (z. B. Datenbankzugriff oder Services) vor.
-Mocks werden hier häufig eingesetzt, um noch nicht integrierte Unterschichten zu simulieren.
 ===== Bottom-Up-Integration =====
-Bei dieser Strategie testen wir zuerst die Integration von Komponenten, die keine weiteren Abhängigkeiten haben.
+| {{:modul:m450:learningunits:lu15:bottomup.png?600|}} | Bei dieser Strategie testen wir zuerst die Integration von Komponenten, die keine weiteren Abhängigkeiten haben. Wir beginnen mit den grundlegenden Bausteinen des Systems (z. B. Datenbank- oder Utility-Funktionen) und arbeiten uns schrittweise nach oben. Höhere Schichten werden erst integriert, wenn ihre Abhängigkeiten bereits getestet wurden. |
-Wir beginnen mit den grundlegenden Bausteinen des Systems (z. B. Datenbank- oder Utility-Funktionen) und arbeiten uns schrittweise nach oben.
-Höhere Schichten werden erst integriert, wenn ihre Abhängigkeiten bereits getestet wurden.
 ==== Basierend auf Unittests ====