Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- modul:m450:learningunits:lu16:behant_python [2025/10/23 08:17] – kmaurizi
+++ modul:m450:learningunits:lu16:behant_python [2025/10/23 09:34] (aktuell) – [Vergleich zu Unit Tests] kmaurizi
@@ Zeile 1: / Zeile 1: @@
-====== LU16e - Behaviour Driven Development (BDD) mit Behave ======
+====== LU16e – Behaviour Driven Development (BDD) in Python ======
 ===== Einführung =====
@@ Zeile 16: / Zeile 16: @@
   * Entwicklungsschritte von der Benutzerstory bis zum Test automatisieren
   * Früh Feedback erhalten, ob das System das gewünschte Verhalten zeigt
+----
+===== Ausgangssituation: Eine kleine App =====
+Stell dir vor, du entwickelst eine kleine **Applikation**, z. B. einen **Rechner**, der einfache Operationen (Addition, Subtraktion usw.) ausführt.
+Diese App soll so getestet werden, dass auch **nicht-technische Personen** verstehen, was überprüft wird.
+Das Ziel ist nicht, die App zu programmieren – sondern **ihr Verhalten zu beschreiben und zu testen**, wie sie sich aus Sicht der Benutzer:innen verhalten *sollte*.
 ----
 ===== Aufbau eines Behave-Projekts =====
-Ein Behave-Projekt besteht aus folgenden Ordnern und Dateien:
+Ein Behave-Projekt ist typischerweise so aufgebaut:
 <code>
 project/
- ├── features/
+ ├── app/                 <-- hier liegt der Quellcode der App (z. B. calculator.py)
+ ├── features/            <-- hier liegen die BDD-Tests
  │    ├── calculator.feature
  │    └── steps/
@@ Zeile 32: / Zeile 41: @@
   * **''.feature''-Dateien** enthalten Szenarien in Gherkin-Sprache
   * **''.py''-Dateien** im Unterordner ''steps/'' enthalten die Python-Schritte dazu
+  * Das App-Modul (''app/calculator.py'') ist die **getestete Anwendung**
 ----
 ===== Gherkin-Syntax =====
-Gherkin ist eine einfache Sprache, um Verhalten zu beschreiben.
+Gherkin ist eine leicht lesbare Sprache, um das gewünschte Verhalten eines Systems zu beschreiben.
-Jede Datei beschreibt ein **Feature** (eine Funktion oder Benutzerstory).
+Jede Feature-Datei beschreibt **eine Funktionalität** oder **Benutzerstory**.
 Beispiel:
-```gherkin
+<code>
 Feature: Einfacher Taschenrechner
-  Um einfache Rechnungen zu machen
+  Um einfache Rechnungen durchführen zu können
   Möchte ich zwei Zahlen addieren können
   Scenario: Zwei Zahlen addieren
-    Given ich habe 50 in den Rechner eingegeben
+    Given ich habe 50 in die App eingegeben
-    And ich habe 70 in den Rechner eingegeben
+    And ich habe 70 in die App eingegeben
-    When ich drücke addieren
+    When ich die Additionsfunktion ausführe
-    Then sollte das Ergebnis 120 auf dem Bildschirm stehen
+    Then sollte das Ergebnis 120 auf dem Bildschirm erscheinen
-```
+</code>
 **Schlüsselwörter:**
@@ Zeile 63: / Zeile 73: @@
 ----
-===== Schrittdefinitionen (Step Definitions) =====
+===== Schrittdefinitionen und getestete App =====
-Jeder Schritt im Feature wird mit einer Python-Funktion verknüpft.
+<WRAP group>
+<WRAP half column>
+**Feature Steps (Testcode)**
 <code python>
 from behave import given, when, then
+from app.calculator import Calculator  # zu testende App
-@given('ich habe {zahl:d} in den Rechner eingegeben')
+@given('ich habe {zahl:d} in die App eingegeben')
-def step_eingabe(context, zahl):
+def step_input_number(context, zahl):
-    if not hasattr(context, "zahlen"):
+    # Erstellt (falls nötig) eine neue App-Instanz
-        context.zahlen = []
+    if not hasattr(context, "calc"):
-    context.zahlen.append(zahl)
+        context.calc = Calculator()
+    context.calc.enter_number(zahl)
-@when('ich drücke addieren')
+@when('ich die Additionsfunktion ausführe')
-def step_add(context):
+def step_perform_add(context):
-    context.resultat = sum(context.zahlen)
+    # Führt die gewünschte Operation aus
+    context.result = context.calc.add()
-@then('sollte das Ergebnis {erwartet:d} auf dem Bildschirm stehen')
+@then('sollte das Ergebnis {expected:d} auf dem Bildschirm erscheinen')
-def step_pruefen(context, erwartet):
+def step_verify_result(context, expected):
-    assert context.resultat == erwartet
+    # Überprüft das sichtbare Resultat der App
+    assert context.result == expected
 </code>
-**Wichtig:**
+</WRAP>
-  * Der ''context'' ist ein gemeinsames Objekt für alle Schritte eines Szenarios
-  * Parameter in geschweiften Klammern ''{zahl:d}'' werden automatisch geparst (z. B. als int)
-----
+<WRAP half column>
+**App-Code (getestete Anwendung)**
+<code python>
+# app/calculator.py
+class Calculator:
+    def __init__(self):
+        # interner Speicher für eingegebene Zahlen
+        self.numbers = []
+    def enter_number(self, value):
+        # Zahl zur Eingabeliste hinzufügen
+        self.numbers.append(value)
+    def add(self):
+        # Beispiel-Implementierung: summiert alle Werte
+        result = sum(self.numbers)
+        # leert Eingaben für nächsten Vorgang
+        self.numbers.clear()
+        return result
+</code>
+</WRAP>
+</WRAP>
+**Hinweise:**
+  * Das Modul ''calculator.py'' ist die **zu testende Applikation**, nicht Teil des Tests selbst.
+  * Die Datei ''calculator_steps.py'' beschreibt nur das **erwartete Verhalten**.
+  * Der ''context'' erlaubt den Austausch von Objekten (z. B. der App) zwischen den Schritten.
+  * Jeder ''Given/When/Then''-Schritt entspricht einem Teil der Benutzerinteraktion.
 ===== Tests ausführen =====
-Im Terminal im Projektordner:
+Im Terminal:
-'''
+<code>
 behave
-'''
+</code>
-Ergebnis:
+Ergebnis (Auszug):
 <code>
 Feature: Einfacher Taschenrechner
   Scenario: Zwei Zahlen addieren
-    Given ich habe 50 in den Rechner eingegeben
+    Given ich habe 50 in die App eingegeben
-    And ich habe 70 in den Rechner eingegeben
+    And ich habe 70 in die App eingegeben
-    When ich drücke addieren
+    When ich die Additionsfunktion ausführe
-    Then sollte das Ergebnis 120 auf dem Bildschirm stehen
+    Then sollte das Ergebnis 120 auf dem Bildschirm erscheinen
 feature passed, 0 failed
@@ Zeile 113: / Zeile 158: @@
 ===== Vorteile von Behave =====
-  * Tests sind **leicht lesbar** für alle Beteiligten
+  * Tests sind **verständlich** für Entwickler:innen und Fachpersonen
-  * **Klarer Bezug** zu Anforderungen / User Stories
+  * **Klarer Bezug** zu Anforderungen oder Benutzerstories
-  * **Wiederverwendbare Schritte** in Python
+  * Schritte sind **wiederverwendbar** für mehrere Szenarien
-  * **Automatisierbar** in CI/CD-Pipelines (z. B. GitHub Actions, Jenkins)
+  * Einfach **automatisierbar** in CI/CD-Pipelines (z. B. GitHub Actions, Jenkins)
 ----
 ===== Vergleich zu Unit Tests =====
-| Aspekt | Unit Test | BDD (Behave) |
+^ Aspekt ^ Unit Test ^ BDD (Behave) ^
-|---------|------------|--------------|
+| Fokus | einzelne Funktion / Methode | Verhalten aus Nutzersicht |
-| Fokus | einzelne Funktion / Klasse | Verhalten aus Nutzersicht |
 | Sprache | Code (Python) | Gherkin (natürliche Sprache) |
 | Zielgruppe | Entwickler:innen | Fachpersonen + Entwickler:innen |
-| Beispiel | `assert add(2,3)==5` | „Given ich habe 2 und 3, When ich addiere, Then erhalte ich 5“ |
+| Beispiel | ''assert add(2,3)==5'' | „Given ich habe 2 und 3 eingegeben, When ich addiere, Then erhalte ich 5“ |
 ----
@@ Zeile 133: / Zeile 177: @@
 Installation mit ''pip'':
-'''
+<code>
 pip install behave
-'''
+</code>
 ----
@@ Zeile 153: / Zeile 197: @@
 ----
+{{tag>MXXX-LU16e}}
+[[https://creativecommons.org/licenses/by-nc-sa/4.0/|{{https://i.creativecommons.org/l/by-nc-sa/4.0/88x31.png}}]]