03 Grundlagen des Testens: Coverage Konzepte Quiz

Richtige Antwort: B

Statement Coverage (C0) misst den Prozentsatz der ausführbaren Anweisungen in deinem Code, die während des Testens ausgeführt werden.

Formel:

\(\text{C0} = \frac{\text{Ausgeführte Anweisungen}}{\text{Gesamte Anweisungen}} \times 100\%\)

Beispiel:

def example(x):
    if x > 0:          # Statement 1
        print("pos")   # Statement 2
    return x           # Statement 3

Wenn du mit example(5) testest:

• Ausgeführte Anweisungen: 1, 2, 3 (alle 3)
• C0 = 3/3 = 100%

Wenn du mit example(-5) testest:

• Ausgeführte Anweisungen: 1, 3 (Anweisung 2 übersprungen)
• C0 = 2/3 = 67%

Warum andere Optionen falsch sind:

• A: Das wäre “Function Coverage”, nicht Statement Coverage
• C: Coverage geht um Ausführung, nicht ein einfaches Verhältnis von Tests zu Code
• D: Das beschreibt Branch-Ergebnisse, nicht Anweisungsausführung

Richtige Antwort: A

Branch Coverage (C1) misst den Prozentsatz der Entscheidungsergebnisse (True/False-Branches), die während des Testens ausgeführt werden.

Formel:

\(\text{C1} = \frac{\text{Ausgeführte Branches}}{\text{Gesamte Branches}} \times 100\%\)

Beispiel:

def example(x):
    if x > 0:          # Decision with 2 branches: True, False
        return "pos"   # True branch
    return "neg"       # False branch (implicit else)

Wenn du mit example(5) testest:

• True Branch: Ausgeführt
• False Branch: NICHT ausgeführt
• C1 = 1/2 = 50%

Um 100% C1 zu erreichen, brauchst du BEIDES:

• example(5) → True Branch
• example(-5) → False Branch

Warum andere Optionen falsch sind:

• B: If-Anweisungen zählen ist keine Coverage; es ist eine Code-Metrik
• C: Das ist kein Standard-Coverage-Maß
• D: Das beschreibt “Execution Count”, nicht Branch Coverage

Richtige Antwort: B

Ein Coverage-Kriterium ist eine formale Regel, die definiert, welche Elemente eines Programms von einer Testsuite ausgeführt (abgedeckt) werden müssen, damit diese Suite nach diesem Kriterium als “angemessen” gilt.

Beispiele für Coverage-Kriterien:

• Statement Coverage (C0): Jede Anweisung muss mindestens einmal ausgeführt werden
• Branch Coverage (C1): Jedes Branch-Ergebnis muss mindestens einmal ausgeführt werden
• Path Coverage: Jeder mögliche Pfad durch den Code muss ausgeführt werden
• Condition Coverage: Jeder boolesche Teilausdruck muss True und False sein

Warum das wichtig ist:

Verschiedene Kriterien haben unterschiedliche Stärken (Fehlererkennung) und Kosten (Anzahl benötigter Tests). Die Wahl des richtigen Kriteriums hängt ab von:

• Risikoniveau des Codes
• Verfügbare Test-Ressourcen
• Erforderliches Vertrauensniveau

Warum andere Optionen falsch sind:

• A: Das ist eine Performance-Metrik, kein Coverage-Kriterium
• C: Coverage geht darum, was getestet wird, nicht um eine feste Anzahl
• D: Coverage-Kriterien sind für Test-Angemessenheit, nicht für Benotung

Richtige Antwort: B

Subsumption bedeutet, dass ein Coverage-Kriterium “stärker” ist als ein anderes. Wenn Kriterium A Kriterium B subsumiert, dann garantiert das Erreichen von 100% Coverage unter A automatisch 100% Coverage unter B.

C1 subsumiert C0, weil:

Um beide Branches einer Entscheidung abzudecken:

if condition:
    statement_A   # True branch
else:
    statement_B   # False branch

• Du MUSST statement_A ausführen (um True Branch abzudecken)
• Du MUSST statement_B ausführen (um False Branch abzudecken)
• Daher sind beide Anweisungen abgedeckt

Das Umgekehrte gilt NICHT:

Du kannst 100% C0 ohne 100% C1 haben:

def risky(x, logging=True):
    if logging:
        log_event(x)   # Always executed if logging=True
    return process(x)  # Always executed

Nur mit logging=True testen ergibt:

• C0: 100% (alle Anweisungen ausgeführt)
• C1: 50% (nur True Branch von if logging getestet)

Warum andere Optionen falsch sind:

• A: Subsumption geht um Coverage, nicht Geschwindigkeit
• C: Das Gegenteil ist wahr; C1 ist gründlicher
• D: C1 erfordert typischerweise MEHR Tests (muss beide Branches abdecken)

Richtige Antwort: B

Test-Angemessenheit ist eine Eigenschaft einer Testsuite relativ zu einem spezifischen Coverage-Kriterium. Eine Testsuite ist angemessen, wenn sie 100% Coverage nach dem gewählten Kriterium erreicht.

Beispiele:

• C0-angemessen: Jede Anweisung wird von mindestens einem Test ausgeführt
• C1-angemessen: Jedes Branch-Ergebnis wird von mindestens einem Test ausgeführt

Wichtige Unterscheidung:

• Angemessen bedeutet “erfüllt die Anforderungen des Kriteriums”
• Angemessen bedeutet NICHT “Tests sind korrekt” oder “Code ist fehlerfrei”

Eine Testsuite kann C0-angemessen sein und trotzdem:

• Schwache Assertions haben
• Grenzfälle verpassen
• Tatsächliche Bugs nicht erkennen

Warum andere Optionen falsch sind:

• A: Tests bestehen geht um Korrektheit, nicht Angemessenheit
• C: Angemessenheit geht nicht um Anzahl; es geht um Coverage
• D: Geschwindigkeit ist ein Performance-Thema, nicht Angemessenheit

Richtige Antwort: B

Um 100% C1 bei diesem Code zu erreichen, musst du abdecken:

1. True Branch (value > 0 ist True) → Führt return "positive" aus
2. False Branch (value > 0 ist False) → Führt return "negative" aus

Durch das Abdecken beider Branches hast du notwendigerweise ausgeführt:

• Zeile 2: if value > 0: (die Bedingung selbst)
• Zeile 3: return "positive" (True Branch Anweisung)
• Zeile 5: return "negative" (False Branch Anweisung)

Alle 3 ausführbaren Anweisungen sind abgedeckt, also C0 = 100%.

Visueller Beweis:

Warum andere Optionen falsch sind:

• A: C1 “zählt” keine Anweisungen; es zählt Branch-Ergebnisse
• C: Testlänge hat nichts mit Subsumption zu tun
• D: Die Reihenfolge der Berechnung beeinflusst die Beziehung nicht

Du kannst deine Antwort mit pytest-cov überprüfen! Erstelle diese Dateien:

src/grading.py:

def categorize(score):
    if score >= 90:
        return "A"
    elif score >= 80:
        return "B"
    elif score >= 70:
        return "C"
    else:
        return "F"

tests/test_grading.py:

from src.grading import categorize

def test_high_score():
    assert categorize(95) == "A"

Coverage ausführen:

uv run pytest tests/ --cov=src --cov-report=term-missing

Voraussetzungen: Python 3.12+, uv Package Manager, pytest und pytest-cov installiert (uv add pytest pytest-cov).

Richtige Antwort: B

Zählen wir die ausführbaren Anweisungen:

def categorize(score):
    if score >= 90:      # Statement 1 (condition check)
        return "A"       # Statement 2 (executed)
    elif score >= 80:    # Statement 3 (NOT executed - short-circuit)
        return "B"       # Statement 4 (NOT executed)
    elif score >= 70:    # Statement 5 (NOT executed)
        return "C"       # Statement 6 (NOT executed)
    else:
        return "F"       # Statement 7 (NOT executed)

Mit categorize(95):

• Anweisung 1: Ausgeführt (Bedingung ist True)
• Anweisung 2: Ausgeführt (gibt “A” zurück)
• Anweisungen 3-7: NICHT ausgeführt (Funktion kehrt früh zurück)

Berechnung:

• Ausgeführt: 2 Anweisungen
• Gesamt: 5 Anweisungen (die 4 returns + der Funktionseintritt/erste Bedingung)
• C0 = 2/5 = 40%

Hinweis: Genaue Zahlen können je nachdem variieren, wie dein Coverage-Tool Anweisungen zählt (manche zählen if und elif separat, manche nicht). Die Kernaussage ist, dass nur ein kleiner Teil des Codes ausgeführt wird.

Warum andere Optionen falsch sind:

• A (25%): Zu niedrig; wir haben mehr als 1 von 4 ausgeführt
• C (50%): Wir haben nicht die Hälfte der Anweisungen ausgeführt
• D (100%): Wir haben eindeutig die B, C und F Branches übersprungen

Überprüfe deine Antwort mit pytest-cov mit aktivierter Branch Coverage:

tests/test_grading.py:

from src.grading import categorize

def test_scores():
    assert categorize(95) == "A"
    assert categorize(85) == "B"

Mit Branch Coverage ausführen:

uv run pytest tests/ --cov=src --cov-branch --cov-report=term-missing

Das --cov-branch Flag aktiviert Branch Coverage Reporting. Achte auf die “Branch” und “BrPart” Spalten in der Ausgabe.

Richtige Antwort: B

Identifizieren wir alle Branches:

if score >= 90:      # Branch 1 (True), Branch 2 (False)
    return "A"
elif score >= 80:    # Branch 3 (True), Branch 4 (False)
    return "B"
elif score >= 70:    # Branch 5 (True), Branch 6 (False)
    return "C"
else:
    return "F"

Gesamte Branches: 6 (jede Bedingung hat True und False Ergebnisse)

Mit unseren Tests:

Abgedeckte Branches: 1, 2, 3 = 3 Branches NICHT abgedeckte Branches: 4, 5, 6 (brauchen Scores wie 75 und 50)

Berechnung:

C1 = 3/6 = 50%

Um 100% C1 zu erreichen, bräuchten wir:

• categorize(95) → A (deckt score >= 90 True ab)
• categorize(85) → B (deckt score >= 90 False, score >= 80 True ab)
• categorize(75) → C (deckt score >= 80 False, score >= 70 True ab)
• categorize(50) → F (deckt score >= 70 False ab)

Richtige Antwort: B

Die “Missing” Spalte zeigt Zeilennummern, die von keinem Test in deiner Testsuite nicht ausgeführt wurden.

Was das bedeutet:

• Zeilen 18, 19, 20: Nicht von Tests abgedeckt
• Zeilen 35, 36, 37: Nicht von Tests abgedeckt
• Diese Zeilen repräsentieren ungetestete Codepfade

Was dagegen zu tun ist:

1. Schau dir den Code an diesen Zeilen an
2. Verstehe warum sie nicht ausgeführt wurden:
   • Ist es ein bedingter Branch, der nicht ausgelöst wurde?
   • Ist es Fehlerbehandlungscode?
   • Ist es toter Code, der entfernt werden sollte?
3. Füge Tests hinzu, die diese Zeilen ausführen (wenn es gültiger Code ist)

Beispielszenario:

# Line 18-20 might be:
if special_case:
    handle_special()
    return early_result

# Your tests never triggered special_case = True

Warum andere Optionen falsch sind:

• A: Coverage-Tools erkennen keine Syntaxfehler; sie messen Ausführung
• C: Fehlende Zeilen sind nicht unbedingt schlecht; sie brauchen nur Tests
• D: Die Wichtigkeit von Code hängt nicht davon ab, ob er getestet ist

Richtige Antwort: B

Analysieren wir, was “Missing: 3, 7” bedeutet:

• Zeile 3 fehlt: return "Error" wurde nie ausgeführt
  • Das bedeutet value is None war nie True
  • Also war value is None immer False
• Zeile 7 fehlt: return "Zero" wurde nie ausgeführt
  • Das bedeutet value == 0 war nie True
  • Also war value == 0 immer False

Was wahrscheinlich getestet wurde:

• validate(5) → Positive (Zeilen 2, 4, 6, 8 ausgeführt)
• validate(-3) → Negative (Zeilen 2, 4, 5 ausgeführt)

Was NICHT getestet wurde:

• validate(None) → Würde Zeile 3 ausführen
• validate(0) → Würde Zeile 7 ausführen

Warum andere Optionen falsch sind:

• A: Zeile 5 (return "Negative") fehlt NICHT, also war value < 0 irgendwann True
• C: Zeile 5 fehlt NICHT, also wurde value < 0 abgedeckt
• D: Zeilen 3 und 7 fehlen, also wurden nicht alle Bedingungen vollständig getestet

Richtige Antwort: C

100% Coverage bedeutet, dass jede Anweisung ausgeführt wurde, aber sagt nichts darüber aus:

• Ob Assertions korrektes Verhalten verifizieren
• Ob alle wichtigen Eingaben getestet wurden
• Ob die Logik tatsächlich korrekt ist

Beispiel für 100% Coverage ohne Bug-Erkennung:

def divide(a, b):
    return a / b   # Bug: doesn't handle b=0

def test_divide():
    result = divide(10, 2)
    assert result is not None  # Weak assertion! Doesn't check value

Dies erreicht 100% Coverage, aber:

• Verifiziert nicht das tatsächliche Ergebnis (sollte 5 sein)
• Testet b=0 nicht (was abstürzen würde)
• Gibt falsches Vertrauen

Was Coverage dir SAGT:

• Welcher Code überhaupt nicht ausgeführt wurde (definitiv nicht getestet)
• Lücken in deiner Testsuite

Was Coverage dir NICHT sagt:

• Ob Tests tatsächlich Korrektheit verifizieren
• Ob Grenzfälle behandelt werden
• Ob der Code fehlerfrei ist

Warum andere Optionen falsch sind:

• A: Korrektheit erfordert richtige Assertions, nicht nur Ausführung
• B: Du kannst 100% Coverage mit sehr wenigen Eingaben erreichen
• D: Coverage misst Ausführung, nicht Korrektheit

Richtige Antwort: C

Der Test erreicht hohe Coverage durch Ausführen von:

• total = sum(items) → 60
• if discount_percent > 0: → True
• discount = total * (discount_percent / 100) → 6
• total = total - discount → 54
• return total → gibt 54 zurück

Aber die Assertion assert result > 0 ist extrem schwach:

• Sie würde für result = 1 bestehen (falsch!)
• Sie würde für result = 100000 bestehen (falsch!)
• Sie würde für result = 54 bestehen (korrekt)

Ein richtiger Test sollte den exakt erwarteten Wert verifizieren:

def test_calculate_total_with_discount():
    # Arrange
    items = [10, 20, 30]
    discount_percent = 10

    # Act
    result = calculate_total(items, discount_percent)

    # Assert - verify the exact expected value
    expected = 54  # (10+20+30) - 10% = 60 - 6 = 54
    assert result == expected

Kernaussage:

Coverage sagt dir, dass der Code gelaufen ist, aber nur gute Assertions sagen dir, dass der Code korrekt funktioniert hat.

Warum andere Optionen falsch sind:

• A: Der Test erreicht wahrscheinlich gute Coverage (alle Zeilen ausgeführt)
• B: Die Syntax ist gültiges Python
• D: Obwohl wahr, ist die schwache Assertion das kritische Problem

Richtige Antwort: B

Eine falsche Berechnungsformel könnte trotzdem perfekt ausgeführt werden und 100% Coverage erreichen, während sie falsche Ergebnisse produziert.

Beispiel:

def calculate_area(radius):
    return 3.14 * radius * radius  # Bug: should use math.pi

def test_area():
    result = calculate_area(10)
    assert result is not None  # Passes! But result is slightly wrong

Dies erreicht 100% Coverage, aber:

• Die Formel verwendet 3.14 statt math.pi
• Das Ergebnis ist ungefähr 314 statt 314.159…
• Eine schwache Assertion fängt das nicht ab

Was Coverage (indirekt) erkennen KANN:

• A (fehlender Import): Würde abstürzen, wenn dieses Modul verwendet wird
• C (Syntaxfehler): Python läuft gar nicht
• D (undefinierte Variable): Würde NameError auslösen, wenn ausgeführt

Kernaussage:

Coverage erkennt Abstürze (Code, der nicht läuft), aber nicht logische Fehler (Code, der läuft, aber falsche Ausgaben produziert).

Deshalb brauchst du:

1. Gute Coverage (Code wird ausgeführt)
2. Starke Assertions (Verhalten wird verifiziert)
3. Grenzfall-Tests (Randbedingungen werden geprüft)

Richtige Antwort: B

70% Coverage kann akzeptabel sein, wenn der nicht abgedeckte Code ist:

1. Toter Code, der entfernt werden sollte
2. Defensive Fehlerbehandler für “unmögliche” Bedingungen
3. Plattformspezifischer Code, der für die aktuelle Umgebung nicht relevant ist
4. Debug/Logging-Code, der nicht kritisch zu testen ist

Beispiele für akzeptablen nicht abgedeckten Code:

def process_file(path):
    try:
        with open(path) as f:
            return f.read()
    except PermissionError:
        # Only happens in restricted environments
        log_error("Permission denied")
        return None
    except Exception as e:
        # Defensive catch-all, should "never" happen
        log_critical(f"Unexpected: {e}")
        raise

Die except-Blöcke könnten nicht abgedeckt sein, wenn deine Tests nur zugängliche Dateien verwenden. Das ist oft OK.

Wann 70% NICHT akzeptabel ist:

• Kern-Geschäftslogik ist nicht abgedeckt
• Happy-Path-Funktionalität ist nicht getestet
• Die 30% enthalten kritischen Code

Warum andere Optionen falsch sind:

• A: 100% ist nicht immer praktikabel oder sinnvoll
• C: Kosten allein sind kein guter Grund; priorisiere kritischen Code
• D: Projektphase bestimmt nicht akzeptable Coverage

Richtige Antwort: B

Coverage und Korrektheit sind verschiedene Konzepte:

Hohe Coverage + schwache Assertions = Falsches Vertrauen

def test_broken():
    result = buggy_function()  # Runs the code (coverage!)
    assert result is not None   # Doesn't check correctness

Niedrige Coverage + starke Assertions = Unvollständiges Testen

def test_one_path():
    assert calculate(10) == 100  # Correct for this input
    # But what about calculate(-5)? calculate(0)?

Ideal: Hohe Coverage + starke Assertions + gutes Testdesign

def test_positive():
    assert calculate(10) == 100

def test_negative():
    assert calculate(-5) == -50

def test_zero():
    assert calculate(0) == 0

def test_edge_case():
    assert calculate(0.001) == 0.01

Warum andere Optionen falsch sind:

• A: Coverage beweist Ausführung, nicht Korrektheit
• C: Niedrige Coverage bedeutet ungetesteten Code, nicht inkorrekten Code
• D: Sie sind komplementäre, aber unterschiedliche Konzepte

Teste deine Hypothese! Erstelle diese Dateien und führe Coverage aus:

src/age_classifier.py:

def classify_age(age):
    if age < 0:
        return "Invalid"
    elif age < 18:
        return "Minor"
    elif age < 65:
        return "Adult"
    else:
        return "Senior"

tests/test_age.py (initiale Tests, die Zeile 9 nicht abdecken):

from src.age_classifier import classify_age

def test_ages():
    assert classify_age(-5) == "Invalid"
    assert classify_age(17) == "Minor"
    assert classify_age(30) == "Adult"

Coverage ausführen, um Zeile 9 als fehlend zu sehen:

uv run pytest tests/ --cov=src --cov-report=term-missing

Dann füge deinen gewählten Test hinzu und führe erneut aus, um zu verifizieren, dass er Zeile 9 abdeckt!

Richtige Antwort: D

Zeile 9 (return "Senior") ist im else-Branch, der ausgeführt wird, wenn:

• age < 0 ist False (age ist 0 oder positiv)
• age < 18 ist False (age ist 18 oder älter)
• age < 65 ist False (age ist 65 oder älter)

Also brauchen wir age >= 65, um Zeile 9 zu erreichen.

Analyse jeder Option:

Nur Option D deckt Zeile 9 ab.

Warum andere Optionen falsch sind:

• A: Deckt Zeile 3 ab (age < 0 ist True)
• B: Deckt Zeile 5 ab (age < 18 ist True)
• C: Deckt Zeile 7 ab (age < 65 ist True)

Richtige Antwort: B

Verfolgen wir, was jede fehlende Zeile abdeckt:

Zeile 3 (raise ValueError): Braucht weight <= 0

• weight = -1 → Zeile 2 ist True → Zeile 3 wird ausgeführt

Zeile 8 (return base_cost * 1.5): Braucht weight > 0 UND express=True

• weight = 5, express = True → Erreicht Zeile 7, Zeile 7 ist True → Zeile 8 wird ausgeführt

Analyse der Optionen:

Nur Option B deckt BEIDE fehlenden Zeilen ab.

Warum andere Optionen falsch sind:

• A: Deckt nur Zeile 8 ab, nicht Zeile 3
• C: Deckt nur Zeile 3 ab, nicht Zeile 8
• D: Beide Tests haben positives weight, decken nie Zeile 3 ab

Richtige Antwort: B

BrPart steht für “Branch Partial” - es zählt Branches, bei denen nur ein Ergebnis (True ODER False) getestet wurde, aber nicht beide.

Beispiel für teilweise Branch Coverage:

def process(value, debug=True):
    if debug:           # Branch: tested only when debug=True
        log(value)
    return transform(value)

Wenn alle Tests debug=True verwenden:

• True Branch: Abgedeckt (log wird aufgerufen)
• False Branch: NICHT abgedeckt (log wird übersprungen)
• Dieser Branch ist “teilweise abgedeckt” → trägt zu BrPart bei

Spaltenbedeutungen:

• Stmts: Gesamte Anweisungen (20)
• Miss: Nicht ausgeführte Anweisungen (2)
• Branch: Gesamte Branch-Ergebnisse (10)
• BrPart: Teilweise abgedeckte Branches (3)
• Cover: Gesamter Coverage-Prozentsatz (82%)

Um teilweise Branches zu beheben:

Füge Tests hinzu, die das gegenteilige Bedingungsergebnis auslösen.

Warum andere Optionen falsch sind:

• A: BrPart zählt unvollständige Branches, nicht vollständige
• C: Teilweise Coverage ist kein Grund, Code zu löschen
• D: Dies ist eine Coverage-Metrik, kein Fehlerbericht

Richtige Antwort: C

Für ein Finanztransaktionssystem ist hohe Coverage wichtig, weil:

• Bugs können finanzielle Verluste verursachen
• Grenzfälle bei Geldhandhabung sind kritisch
• Regulatorische Anforderungen können Tests vorschreiben

Warum 85-90% statt 100%:

• 100% ist oft unpraktisch (Fehlerbehandler, Debug-Code)
• 100% kann dazu führen, Implementierungsdetails zu testen
• Fokus sollte auf sinnvoller Coverage kritischer Pfade liegen

Best Practice für kritische Systeme:

1. Basis-Schwellenwert setzen (85-90%)
2. 100% bei kritischen Modulen erfordern (z.B. transactions.py)
3. Niedrigere Coverage bei nicht-kritischen Hilfsfunktionen erlauben
4. Starke Assertions durchsetzen, nicht nur Ausführung

Beispiel CI-Konfiguration:

- name: Run tests with coverage
  run: pytest --cov=src --cov-fail-under=85 --cov-report=term-missing

Warum andere Optionen falsch sind:

• A (50%): Zu niedrig für Finanzsysteme
• B (70%): Industriestandard für allgemeine Apps, aber Finanzen braucht mehr
• D (100%): Unpraktisch und kann dazu führen, die Metrik zu manipulieren

Richtige Antwort: B

CI Coverage-Integration dient als Qualitäts-Gate, das:

1. Coverage bei jedem Pull Request misst
2. Den Build fehlschlagen lässt, wenn Coverage unter den Schwellenwert fällt
3. Verhindert, dass sich “Coverage-Schulden” ansammeln
4. Coverage für das Team sichtbar macht

Wie es funktioniert:

# In GitHub Actions workflow
- name: Run tests with coverage
  run: uv run pytest --cov=src --cov-fail-under=80

# If coverage < 80%, the workflow fails
# PR cannot be merged until coverage is restored

Vorteile:

• Automatische Durchsetzung: Keine manuelle Überprüfung nötig
• Frühes Feedback: Entwickler wissen sofort, ob sie mehr Tests brauchen
• Trend-Schutz: Coverage kann nicht stillschweigend abnehmen
• Team-Sichtbarkeit: Jeder sieht Coverage in PR-Checks

Was CI Coverage NICHT macht:

• Bugs automatisch beheben
• Tests beschleunigen
• Code-Review ersetzen (Menschen werden noch gebraucht)

Warum andere Optionen falsch sind:

• A: CI misst; es behebt nicht
• C: Coverage-Checks fügen Zeit hinzu, reduzieren sie nicht
• D: Code-Review fängt Design-Probleme, die Coverage nicht kann