{"id":551,"date":"2022-01-26T01:34:13","date_gmt":"2022-01-26T01:34:13","guid":{"rendered":"https:\/\/www.cybermedian.com\/de\/?p=551"},"modified":"2022-03-22T15:04:23","modified_gmt":"2022-03-22T07:04:23","slug":"test-drive-development-approach-for-agile-software-development","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/de\/test-drive-development-approach-for-agile-software-development\/","title":{"rendered":"Test-Drive-Entwicklungsansatz f\u00fcr die agile Softwareentwicklung"},"content":{"rendered":"
\n
\n
\n
\n

Heute spricht man oft von agiler Entwicklung.<\/span><\/p>\n

Was ist agile Entwicklung?<\/span><\/span><\/h4>\n

Agile Entwicklung<\/span><\/a>\u00a0\u00a0ist eine Softwareentwicklungsfunktion, die auf sich schnell \u00e4ndernde Anforderungen reagiert.\u00a0Ihre spezifischen Namen, Konzepte, Prozesse und Terminologie variieren.\u00a0Im Vergleich zu \u201e\u00a0<\/span>nicht agil<\/span><\/a>\u00a0\u201c betonen sie die enge Zusammenarbeit zwischen Programmiererteams und Gesch\u00e4ftsexperten, pers\u00f6nliche Kommunikation (wird als effektiver angesehen als schriftliche Dokumentation) und liefern h\u00e4ufig neue Softwareversionen, kleine und\u00a0\u00a0<\/span>selbstorganisierte Teams<\/span><\/a>\u00a0\u00a0f\u00fcr kleine und das Schreiben wertvoller Funktionen sowie Ans\u00e4tze zur Teamorganisation, die sich an sich \u00e4ndernde Bed\u00fcrfnisse anpassen, mit einem st\u00e4rkeren Fokus auf die Rolle der Menschen in der Softwareentwicklung.<\/span><\/p>\n

Es gibt jedoch mehrere \u00e4hnliche Versionen der agilen TDD-Entwicklungsmethoden, wie z. B. TDD: BDD, DDD und ATDD.\u00a0Lassen Sie mich diese Methoden kurz vorstellen, bevor ich TDD im Detail vorstelle:<\/span><\/p>\n

TDD: Testgetriebene Entwicklung<\/span><\/strong><\/p>\n

Test Driven Development<\/span><\/a>\u00a0\u00a0(TDD) ist ein Softwareentwicklungsprozess, der darauf beruht, Softwareanforderungen in Testf\u00e4lle umzuwandeln, bevor die Software vollst\u00e4ndig entwickelt ist, und die gesamte Softwareentwicklung zu verfolgen, indem Software wiederholt f\u00fcr alle Testf\u00e4lle getestet wird.\u00a0Dies ist das Gegenteil davon, zuerst Software zu entwickeln und dann Testf\u00e4lle zu erstellen.\u00a0Einige beliebte Modelle unterst\u00fctzen TDD sehr gut, wie MVC und\u00a0\u00a0<\/span>MVP<\/span><\/a>\u00a0.<\/span><\/p>\n

<\/figure>\n

BDD: Verhaltensgesteuerte Entwicklung (Verhaltensgesteuerte Entwicklung)<\/span><\/strong><\/p>\n

Behavior Driven Development (BDD) ist ebenfalls ein agiler Softwareentwicklungsprozess.\u00a0Es f\u00f6rdert die Zusammenarbeit zwischen Entwicklern, Qualit\u00e4tspr\u00fcfern und Kundenvertretern in Softwareprojekten.\u00a0Es ermutigt Teams, Gespr\u00e4che und konkrete Beispiele zu nutzen, um ein gemeinsames Verst\u00e4ndnis dar\u00fcber zu formulieren, wie die Anwendung funktionieren sollte.\u00a0Es stammt aus der testgetriebenen Entwicklung (TDD).<\/span><\/p>\n

<\/figure>\n

ATDD: Abnahmetestgetriebene Entwicklung<\/span><\/strong><\/p>\n

Um die Realisierung von funktionalem Code durch Unit-Testf\u00e4lle zu f\u00f6rdern, muss das Team erwartete Qualit\u00e4tsstandards und Akzeptanzregeln definieren und die TDD-Praxis der Entwickler und die Leistung der Tester durch einen klaren und konsistenten Akzeptanztestplan (einschlie\u00dflich einer Reihe von Test Szenarien).\u00a0F\u00fcr Entwickler betont es, wie man das System implementiert und wie man es testet.<\/span><\/p>\n

<\/figure>\n

DDD: Design des Dom\u00e4nenlaufwerks<\/span><\/strong><\/p>\n

DDD bezeichnet Domain Driven Design, also dom\u00e4nengetriebene Entwicklung.\u00a0DDD baut tats\u00e4chlich auf dieser Grundlage auf, weil es sich auf das Service Layer Design konzentriert, sich auf die Gesch\u00e4ftsimplementierung konzentriert, Analytik und Design kombiniert und nicht mehr in einem geteilten Zustand h\u00e4lt, um Kundenanforderungen korrekt und umfassend umzusetzen und ein Gesch\u00e4ftsmodell aufzubauen Skalierbarkeit.<\/span><\/p>\n

<\/figure>\n

TDD-Implementierungsplan<\/span><\/span><\/h3>\n

Durch Tests soll die gesamte Entwicklung gef\u00f6rdert werden, aber testgetriebene Entwicklung ist nicht nur eine einfache Testarbeit, sondern ein Prozess der quantifizierenden Anforderungsanalyse, des Designs und der Qualit\u00e4tskontrolle.<\/span><\/em><\/p><\/blockquote>\n

Entwicklungsprinzipien<\/span><\/strong><\/p>\n

Schreiben Sie zuerst den Testcode und dann den Code f\u00fcr die Funktion.<\/span><\/em><\/p><\/blockquote>\n

    \n
  1. Schreiben Sie Testcode gem\u00e4\u00df dem Anforderungsdokument, um die Funktion nicht zu realisieren;<\/span><\/li>\n
  2. Ich m\u00f6chte nicht mit einem Bissen fett sein.\u00a0Beim Testen gro\u00dfer Funktionsbl\u00f6cke sollten Sie diese zum Testen zuerst in kleinere Funktionsbl\u00f6cke aufteilen;<\/span><\/li>\n
  3. Denken Sie daran, keinen Code zu schreiben, um die Funktion zu vervollst\u00e4ndigen, verwenden Sie den einfachstm\u00f6glichen Code, um die Funktion zu implementieren.<\/span><\/li>\n
  4. Wenn die Anforderungen getestet werden k\u00f6nnen, schreiben Sie Testcode und geben Sie diejenigen auf, die nicht getestet werden k\u00f6nnen oder der Meinung sind, dass sie nicht getestet werden m\u00fcssen;<\/span><\/li>\n
  5. Bevor Sie einen Funktionscode \u00e4ndern\/hinzuf\u00fcgen, m\u00fcssen Sie zuerst \u00fcberlegen, ob Sie Testf\u00e4lle \u00e4ndern\/hinzuf\u00fcgen m\u00f6chten;<\/span><\/li>\n
  6. Funktions-\/Testcode, unangemessene Struktur, doppelter Code usw., refaktorisieren Sie rechtzeitig, nachdem der Test bestanden wurde.<\/span><\/li>\n<\/ol>\n

    TDD-Entwicklungsprozess<\/span><\/strong><\/p>\n

      \n
    1. Analysieren und bestimmen Sie ein Zieltestszenario;<\/span><\/li>\n
    2. F\u00fcgen Sie einen Einheitentest hinzu, um die Eingabe und Ausgabe des Testszenarios zu \u00fcberpr\u00fcfen;<\/span><\/li>\n
    3. F\u00fchren Sie den Test durch und erhalten Sie das fehlgeschlagene Testergebnis;<\/span><\/li>\n
    4. Schreiben Sie den einfachsten Funktionscode, um den Test zu bestehen;<\/span><\/li>\n
    5. F\u00fchren Sie den Test erneut aus und pr\u00fcfen Sie, ob der Test erfolgreich ist.<\/span><\/li>\n
    6. Code-Refactoring durchf\u00fchren, einschlie\u00dflich Funktionscode und Unit-Test-Code;<\/span><\/li>\n
    7. Wiederholen Sie die obigen Schritte, bis die Entwicklung abgeschlossen ist.<\/span><\/li>\n<\/ol>\n

      Vorteile von TDD<\/span><\/strong><\/p>\n

        \n
      1. Reduzieren Sie die Belastung f\u00fcr Entwickler<\/span><\/strong>\u00a0.\u00a0Konzentrieren wir uns durch einen klaren Prozess jeweils nur auf einen Punkt, und die Last des Denkens ist geringer.<\/span><\/li>\n
      2. Das Schutznetz<\/span><\/strong>\u00a0.\u00a0Die Abdeckung vollst\u00e4ndiger Unit-Tests bietet ein Schutznetz f\u00fcr den Produktcode, wodurch es einfach wird, ge\u00e4nderten Anforderungen gerecht zu werden oder das Code-Design zu verbessern.\u00a0Wenn Ihre Projektanforderungen also stabil sind, sofort erledigt werden und keine nachtr\u00e4glichen \u00c4nderungen vorgenommen werden, sind die Vorteile von TDD geringer.<\/span><\/li>\n
      3. Anforderungen vorab kl\u00e4ren<\/span><\/strong>\u00a0.\u00a0Das Schreiben von Tests kann uns dabei helfen, \u00fcber die Anforderungen nachzudenken und die Details der Anforderungen im Voraus zu kl\u00e4ren, anstatt unklare Anforderungen erst nach der H\u00e4lfte des Codes zu entdecken.<\/span><\/li>\n
      4. Schnelle R\u00fcckmeldung<\/span><\/strong>\u00a0.\u00a0Viele Leute sagen, dass sich mein Codevolumen erh\u00f6ht, wenn TDD verwendet wird, sodass die Entwicklungseffizienz abnimmt.\u00a0Wenn Sie jedoch keine Komponententests haben, m\u00fcssen Sie sie manuell testen, Sie verbringen viel Zeit damit, Daten vorzubereiten, Apps zu starten, Schnittstellen zu \u00e4ndern usw., und das Feedback ist langsam.\u00a0Um genau zu sein, schnelles Feedback ist ein Vorteil von Unit-Tests.<\/span><\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
        \n
        \n
        \n<\/div>\n
        \n
        \n

        Agile & Scrum-Prinzipien<\/span><\/span><\/h4>\n