Technologie & Testen Mehr Details C · Branchenübliche Konvention Plattform: Allgemein

Test-driven Development

Testgetriebene Entwicklung

Testgetriebene Entwicklung (TDD) wiederholt drei Schritte. Schreibe einen kleinen fehlschlagenden Test. Schreibe den minimalen Code, der besteht. Dann säubere den Code, ohne seine Funktionsweise zu ändern.

Sieh, wie es funktioniert
Du könntest es nennen Test-driven DevelopmentTDDrot-grün-refaktorieren

Sieh, wie es funktioniert

Original bearbeitetes BeispielTestgetriebene Entwicklung

Ein weiteres Beispiel

Ein Entwickler beginnt eine neue Geld-Rundungsregel mit einem Beispieltest, der fehlschlägt. Der kleinste Code macht ihn erfolgreich, dann wird wiederholter Code aufgeräumt, während alle Tests grün bleiben. Tests, die erst nach dem Code geschrieben werden, sind nützlich, aber das ist nicht der Test-First-Zyklus von TDD.

Hauptteile

  1. 01fehlschlagendes Beispiel
  2. 02minimaler bestandener Code
  3. 03Sichere Refaktorierung

Verwenden Sie es, wenn

Verwenden Sie diesen Begriff, wenn jeder nächste Designschritt von einem fehlschlagenden Test geleitet wird und von einer sicheren Bereinigung gefolgt wird.

Nutze es nicht, wenn

Nenne ein Projekt nicht TDD nur, weil es viele Tests hat. Der Code muss der Test-First-Schleife folgen.

In Code verwendeter Name

red → green → refactor

Vor dem Ausliefern

Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.

Anfrage, die Sie kopieren können

Outcome: Complete the task with Testgetriebene Entwicklung (Test-driven Development). User context: Ein Entwickler beginnt eine neue Geld-Rundungsregel mit einem Beispieltest, der fehlschlägt. Der kleinste Code macht ihn erfolgreich, dann wird wiederholter Code aufgeräumt, während alle Tests grün bleiben. Tests, die erst nach dem Code geschrieben werden, sind nützlich, aber das ist nicht der Test-First-Zyklus von TDD. Validation approach: Testgetriebene Entwicklung (Test-driven Development). Why it fits: Verwenden Sie diesen Begriff, wenn jeder nächste Designschritt von einem fehlschlagenden Test geleitet wird und von einer sicheren Bereinigung gefolgt wird. Do not use it when: Nenne ein Projekt nicht TDD nur, weil es viele Tests hat. Der Code muss der Test-First-Schleife folgen. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary): Kein einziger offizieller Standard kontrolliert den gesamten Begriff. Seine Bedeutung kann sich zwischen Teams, Plattformen oder Frameworks ändern. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.

Diese Anfrage prüfen

Review how Testgetriebene Entwicklung (Test-driven Development) is used now. Definition: Testgetriebene Entwicklung (TDD) wiederholt drei Schritte. Schreibe einen kleinen fehlschlagenden Test. Schreibe den minimalen Code, der besteht. Dann säubere den Code, ohne seine Funktionsweise zu ändern. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.

C
Wie offiziell ist dieser Begriff?

Branchenübliche Konvention

Menschen verwenden diesen Begriff oft bei der Arbeit. Die aufgelisteten Quellen können Praxis oder Einschränkungen unterstützen. Sie definieren nicht jeden Teil des Begriffs.

Kein einziger offizieller Standard kontrolliert den gesamten Begriff. Seine Bedeutung kann sich zwischen Teams, Plattformen oder Frameworks ändern.

Umfang
Nur das, was die Quelle abdeckt:Kanonischer Name、Definition、Nutzungshinweise、Ratschläge zur Vermeidung
Dokumentenstatus
stabil
Geprüft am
2026-07-30

Beweisquellen & Umfang

Autoritätsquelle + Begriffsreferenz · Agile Alliance · stabil Test-driven development Umfang: Kanonischer Name、Definition、Nutzungshinweise、Ratschläge zur Vermeidung Rolle hier: Direkte Begriffsreferenz Quelle umfasst: Kanonischer Name, Definition, Nutzungshinweise, Ratschläge zur Vermeidung

Selbst kopieren

Der Browser konnte dies nicht kopieren. Wählen Sie die Anfrage unten aus und kopieren Sie sie selbst.