Kontinuierliche Integration muss immer mit testgetriebener Entwicklung einhergehen?

Question

Ich bin an einem Projekt beteiligt, bei dem wir einen Continuous Integration Server und NUnit für Unit-Tests und Integrationstests verwenden.

Ein Kunde fragte uns neulich, ob wir die Tests vor dem Code schreiben würden... Nun, wir machen das nicht immer so. Vor allem, wenn es sich um komplexe technologische Probleme handelt, die wir zuerst testen möchten, um das Problem und die mögliche Lösung zu verstehen.

Ich würde gerne wissen, ob wir unseren Entwicklungsprozess immer noch als agile Entwicklung bezeichnen können, es den Kunden sagen und nicht lügen.

Answer 1

Ich glaube, Sie verwechseln hier etwas.

Testgetriebene Entwicklung (Test-Driven-Development, TDD) bedeutet nicht unbedingt, dass Sie einen agilen Ansatz verwenden. Sicherlich ist es eine bewährte Praxis, die viele von uns, die agil arbeiten, anwenden, aber TDD kann auch in einem Wasserfallprozess eingesetzt werden und die Spezifikation ersetzen/ergänzen.

Kontinuierliche Integration an sich bedeutet, dass der von Ihrem Team produzierte Code mindestens täglich integriert wird. Dies zwingt nicht nur jedes Teammitglied dazu, kontinuierlich zusammenzuführen/zu prüfen, sondern stellt auch sicher, dass Sie tatsächlich eine Veröffentlichung jedes Builds durchführen können. Da man jeden Tag eine neue Version erstellen kann, unterstützt dies einen agilen Prozess, auch wenn dies im strengen Sinne nicht unbedingt notwendig ist.

Die Verwendung von Tests und deren Integration in den Build-Prozess ist eine Möglichkeit, Ihren Build-Prozess mit automatisierter Qualitätssicherung anzureichern und die Ebene zu vertiefen, auf der die Integration (Integrität) tatsächlich getestet wird.

Answer 2

Solange Sie in kleinen Iterationen entwickeln, sich darauf konzentrieren, ein funktionierendes Produkt zu erhalten, anstatt eine umfangreiche Dokumentation zu erstellen, und der Kunde kontinuierlich in das Projekt eingebunden ist, handelt es sich um agile Entwicklung. Unit-Tests, TDD und Integrationstests sind natürlich gute und sehr empfehlenswerte Praktiken, aber sie entscheiden nicht darüber, ob Ihr Projekt agil ist oder nicht.

Answer 3

In Ermangelung automatisierter Tests überprüft CI lediglich, ob der Code unter der Quellcodekontrolle zwischen den Revisionen in einem kompilierbaren Zustand gehalten wird und ob der einstufige Build ordnungsgemäß funktioniert. Dies ist zwar nützlich, aber nicht so nützlich wie die automatische Überprüfung, dass die Korrektheit des Codes zwischen den Revisionen beibehalten wurde.

In diesem Sinne hätte ich lieber いくらか Überprüfung des Codes zwischen den Check-Ins als keine. Ich habe lieber eine unvollständige Codeabdeckung oder einen unvollständigen Satz funktionaler Tests als gar nichts. Oder noch schlimmer.