Welche bietet mehr Vorteile für eine große Software, sagen wir wie Photoshop?
Auch mit TDD meine ich nicht nur Unit-Tests, weil Sie Unit-Tests auch in D3 verwenden können, nur nicht auf die gleiche Weise wie TDD.
D3: Design Driven Development
TDD: Testgetriebene Entwicklung
DDD = Domain Driven Design
TDD bedeutet, dass Sie vor dem Schreiben einer beliebigen Verhaltenseinheit einen Test für dieses Verhalten und nur für dieses Verhalten durchführen. Erst nachdem diese Tests fehlgeschlagen sind, implementieren Sie das Verhalten. In jeder Inkarnation, die ich gesehen habe, war TDD auf der Ebene einer Methode oder Klasse - vielleicht ein paar Klassen, die zusammenarbeiten. Das Endergebnis ist, dass Sie hoch testbaren und daher sehr locker gekoppelten Code erhalten. Letztendlich geht es bei TDD darum, Code zu erstellen, der getestet werden kann.
DDD ist eine weit abstraktere Philosophie und eine Reihe von Entwurfsmustern, die sich mit dem Entwurf eines großen, skalierbaren und wartbaren Systems befassen. Letztendlich geht es bei DDD darum, ein Code-Ökosystem zu schaffen, das implizit oder explizit wichtige Teile des Domänenwissens erfasst.
Sie sehen also, sie schließen sich nicht gegenseitig aus. So ziemlich jeder, den ich kenne, der DDD kennt, ist auch ein TDD-Enthusiast.
TDD ist weder Bottom-Up- noch Schreiben-Tests vor dem Codieren. Bei TDD geht es darum, Tests zu verwenden, um die Entwicklung voranzutreiben, mit dem Ziel, dass der Code vor der Auslieferung getestet wird. Es beginnt mit der Sicherstellung, dass die Benutzeranforderungen in einer Form geschrieben sind, die automatisierte Benutzerabnahmetests ermöglicht. Es geht weiter durch Integration und Funktionstests bis hin zu Komponententests. Stückprüfungen bilden am Ende den Löwenanteil.
Der Grund, warum Tests zuerst geschrieben werden sollten, ist, dass wenn Sie eine Lösung für ein Problem in Betracht ziehen (entwerfen), Sie automatisch Erwartungen haben, was die Lösung tun soll. Jede Erwartung kann als Test ausgedrückt werden, also warum nicht sofort die Erwartung dokumentieren und gleichzeitig einen automatisierten Test dafür durchführen, um sicherzustellen, dass die Lösung dieses Ziel erreicht?
Ich glaube auch nicht, dass sie sich gegenseitig ausschließen. Ich denke, Sie können TDD verwenden, um zu DDD zu gelangen.
Meiner Meinung nach entwerfen Sie das System, wenn Sie zuerst Tests (in TDD) schreiben. Wenn wir Tests nicht zuerst schreiben können, zeigt dies, dass es eine Mehrdeutigkeit in der Anforderung gibt. Wir können Story vor Test schreiben und sie als Spezifikation Test As Specification verwenden. Nach Bestehen der Tests können wir Tests als Dokument bekannt Test As Document verwenden. Wenn neue Entwickler zum Projekt hinzugefügt werden, können sie diese Tests verwenden, um das Systemgeschäft zu erlernen.
In DDD verwenden Sie einfach Story zum Erstellen von Beziehungen zwischen Objekten. Was bei DDD wichtig ist, ist, dass Sie sich nur auf die Domain konzentrieren sollten. Wenn Sie zum Beispiel Geschäftslogik für Domänen schreiben, sollten Sie sich keine Sorgen darüber machen, ob Sie Entitäten in der Datenbank speichern. Kurz gesagt, sollten Sie beim Schreiben von Geschäftslogik über nichts außerhalb der Domänen nachdenken.