Ich war in zahlreichen Teams, die versuchen, agile Methoden zu üben, und oft sind diese Teams testorientiert. Ist das Testen ein notwendiger Teil des Praktizierens der agilen Methodik oder ist es nur eine XP-Praxis, die im Laufe der Jahre angewendet wurde?

Das Testen ist für Agile von entscheidender Bedeutung, vor allem, weil Agile auf inkrementellen Verbesserungen basiert: Die Schwierigkeit besteht darin, dass es manchmal schwierig ist zu erkennen, wie sich die aktuellen Änderungen auf Ihren alten Code auswirken. Der beste Weg, sicher zu sein, dass Sie etwas nicht kaputt gemacht haben, besteht darin, es zu testen und zu wissen, wie es zu testen ist. Auf diese Weise finden Sie den Fehler sofort und nicht später, wenn Sie genau vergessen haben, was Sie getan haben, als Sie den Code geschrieben haben, der ein altes Feature gebrochen hat.

Der Grund, warum dies anders ist als bei der herkömmlichen Top-Down-Design-Programmierung, ist, dass es in dieser Umgebung a) sehr schwierig zu testen ist, bis Sie das fertige Produkt haben. B) theoretisch berücksichtigen Sie alle Designkriterien gleichzeitig Daher ist es weniger wahrscheinlich, dass Sie eine Entwurfsentscheidung treffen, die frühere Entwurfsentscheidungen verletzt.

Sie sprechen wahrscheinlich von automatisierten Tests, Komponententests, Integrationstests usw. Diese sind für Agile wichtiger als manuelle Tests (mit Testern usw.), da sie zu langsam sind und es daher nicht möglich ist, jede kleine Änderung zu testen, die Sie vornehmen. Da es sich bei Agile um schnelle kleine Iterationen handelt, ist es sehr nützlich, Tests durchzuführen, die die Richtigkeit in Sekunden oder Minuten und nicht in Stunden oder Tagen überprüfen.

Woher wissen Sie, dass Ihr Code funktioniert, wenn Sie keine Tests haben?

Bearbeiten: Die Behauptung, dass Tests nicht beweisen können , dass der Code funktioniert , definiert keinen entscheidenden Begriff, nämlich funktioniert . Was bedeutet es für ein Programm zu arbeiten? Wenn Sie diesen Begriff vage halten, gibt es keine Möglichkeit, zu beweisen oder sicherzustellen, dass ein Programm funktioniert. Je.

Andererseits können Sie Arbeiten als "Verhalten gemäß einer Spezifikation" definieren. Jetzt können Sie nicht nur Tests verwenden, um zu zeigen, dass Code funktioniert, sondern die Tests selbst können als ausführbare Spezifikation des Verhaltens Ihres Codes dienen. Mit anderen Worten, eine gut geschriebene Testsuite definiert, was Arbeit bedeutet.

Diese Denkweise zwingt Sie auch dazu, die Bedeutung eines Fehlers erneut zu untersuchen . Wenn Ihr Code alle Tests besteht, enthält der Code keine Fehler. Wenn sich das System trotzdem nicht so verhält, wie es sollte, ist sein Verhalten nicht richtig spezifiziert. Ich e. Der Fehler befindet sich in der Spezifikation, die durch Tests definiert wurde.

Diese Herangehensweise an die Softwareentwicklung entkoppelt die funktionale Spezifikation eines Systems von seiner Implementierung, was laut jedem Softwareentwicklungsbuch der Welt eine sehr gute Sache ist. Gleichzeitig stellt dieser Ansatz sicher, dass Ihre Implementierung immer der funktionalen Spezifikation entspricht.

Nein, es ist nicht notwendig"

Die Prinzipien von Agile sagen nichts direkt über das Testen aus.

Aber es ist sehr ratsam

Angesichts des Engagements von Agile für einen nachhaltigen Prozess, eine kontinuierliche / inkrementelle Bereitstellung und Softwarequalität ist das automatisierte Testen die derzeit beste Lösung für die meisten Projekte

Ausnahmen (wie von Jörg W Mittag bemerkt) sind nachweislich korrekte Entwicklungswerkzeuge, Meta-Programmiersysteme, die Code generieren, et al. Solche Systeme sind jedoch selten.

Sowohl Agile als auch XP versuchen, Big Design Up Front zu vermeiden . In BDUF werden Anforderungen gesammelt, eine formale Spezifikation erstellt, dann die Codierung durchgeführt und dann die Tests durchgeführt. Dies ist sinnvoll für genau definierte, missions- und lebenswichtige Systeme wie medizinische Geräte, Raumsonden usw.

Agile vermeidet diesen Fluss, weil es bei Problemen, die nicht genau definiert sind, nicht gut funktioniert , zum Beispiel "was auch immer der Client für diese Woche ändert". Wir brauchen noch eine formale Spezifikation, damit wir wissen, was zu tun ist und wann wir fertig sind, aber anstatt eines schriftlichen Dokuments verwenden wir Code in Form von automatisierten Tests.

Automatisierte Komponententests sind schnell zu schreiben, schnell auszuführen und sehr modular / entkoppelt. Dies macht sie zu einer schnellen Möglichkeit, die Anforderungen formal zu spezifizieren und zu überprüfen.