Ist es sinnvoll, die Geschäftsfunktionalität vor einer Codeüberprüfung zu testen?

Es scheint ziemlich pingelig zu sein, die Reihenfolge des Lesens von Code und der Durchführung manueller Tests zu bestimmen, zumal es sich um einen iterativen Prozess handelt.

Da es nicht angegeben ist, besteht die Annahme, dass der Entwickler, der die Arbeit geleistet hat, nicht einfach Code geschrieben und ihn über die Wand geworfen hat. Sie haben es getestet, indem sie eine Kombination aus automatisiertem Testcode geschrieben und einige manuelle Tests über ihre Änderungen durchgeführt haben. Wenn die Codeüberprüfung eingeleitet wird, hat der Entwickler angemessenes Vertrauen, dass das, was er einreicht, korrekt ist, soweit er die Arbeit vor ihm verstanden hat, und die Überprüfung umfasst nicht nur die Produktänderungen, sondern auch den gesamten automatisierten Testcode. Wenn manuelle Tests durchgeführt wurden, sollte der Entwickler erklären können, welche Tests durchgeführt wurden.

Wenn dies zutrifft, sehe ich nicht ein, warum Sie zwischen "Testen der Geschäftsfunktionalität" und "Codeüberprüfung" unterscheiden müssen. Betrachten Sie es vielleicht nicht als "Code-Review", sondern als Peer-Review der Arbeit - des Produktionscodes, der automatisierten Tests und der durchgeführten manuellen Tests. Der Rezensent überprüft wirklich die Qualität all dieser Dinge und führt möglicherweise zusätzliche Sondierungsarbeiten durch, um zu bestätigen, dass es geeignet ist. Je nach Art der Änderungen kann der Aufwand nach Ermessen des Gutachters auf unterschiedliche Dinge gelenkt werden.

Post-Hoc-Tests sind ein Anti-Pattern

Sie haben den Anwendungsfall für die Test-First-Entwicklung kurz und bündig beschrieben. Im Allgemeinen möchten Sie zuerst feststellen, ob Sie das Richtige gebaut haben. Dann müssen Sie feststellen, ob Sie das Ding richtig gebaut haben!

Vor diesem Hintergrund ist die Vorstellung, die Funktionalität von der Korrektheit des Codes zu trennen, eine falsche Dichotomie. Um eine sinnvolle Definition of Done zu erreichen, müssen Sie beides tun. Noch wichtiger ist, dass Design und Tests in enger Zusammenarbeit durchgeführt werden müssen, um unnötige Übergaben und Prozessreibungen zu vermeiden.

Einheiten- und Akzeptanztests als Post-hoc-Aktivitäten zu behandeln, ist oft ein Markenzeichen von Wasserfallprojekten und „großer Vorausplanung“. Es gibt immer noch einige Projektdomänen, in denen dies erforderlich oder notwendig ist, aber wenn Sie die Frage stellen, gehört Ihr spezifisches Projekt wahrscheinlich nicht dazu.

Selbst wenn Sie nicht per se einer agilen Methodik folgen, erzielen Sie mit einer gut ausgearbeiteten Definition of Done und einem Test-First-Ansatz eher die geschäftlichen und technischen Ergebnisse, die Sie benötigen, als zu versuchen, zu bestimmen, welche Post-hoc-Aktivität vorangehen sollte das andere. Die im Allgemeinen richtige Antwort lautet, dass das Testdesign vor dem Codieren oder Testen kommen sollte, sodass alles Post-Hoc (in welcher Reihenfolge) wahrscheinlich ein Anti-Pattern ist.

Ein weiterer Hinweis zu Code-Reviews

Richtig durchgeführt, ist ein Code-Review eine Form des validierten Lernens. Teams, die am Code zusammenarbeiten oder die Code-Diskussionen verwenden, um die gewonnenen Erkenntnisse zu erfassen, sind oft agiler, da dies als eine Form der kontinuierlichen Verbesserung dient.

Die Überprüfung von Pull-Requests, Pair-Programming oder Mob-Programming sind nicht wirklich „Code-Reviews“ im Gating-Sinne des Begriffs. Nach meiner beruflichen Erfahrung übertünchen Teams, die Code-Reviews für Gating-Zwecke verwenden, weitgehend eine Lücke in ihren aktuellen Prozessen oder Tools und sollten wahrscheinlich erwägen, kontinuierliche Integration (CI), automatisierte Tests oder ein besseres Verzweigungsmodell zu ihren Workflows hinzuzufügen. Dies gilt umso mehr, wenn es in den Bewertungen um Stil oder Korrektheit geht. Ersteres sollte eine Arbeitsvereinbarung innerhalb des Teams darstellen, die durch automatisierte Tools durchgesetzt wird, während letzteres am besten durch ausführbare Tests adressiert wird.

Mit anderen Worten, wenn Sie manuelle Code-Reviews als eine Form von Akzeptanztests verwenden, tun Sie es nicht! Es gibt effektivere Ansätze, und das Team sollte zusammenarbeiten, um den für das Projekt am besten geeigneten auszuwählen.

Normalerweise mache ich einen Geschäftstest, nachdem der Code vom Team überprüft und getestet wurde. Dies soll sicherstellen, dass wir den Benutzern qualitativ hochwertige Software zum Testen liefern. Dies verhindert, dass sie offensichtliche Fehler finden, und stärkt ihr Vertrauen in die gelieferte Software.

Dies bedeutet jedoch nicht, dass die Benutzer nicht während der Entwicklung der Funktionalität konsultiert werden können. Es ist äußerst wertvoll, laufende Arbeiten zu zeigen und zu überprüfen, ob Sie auf dem richtigen Weg sind. Dies hilft Ihnen, die richtigen Dinge zu bauen. Wenn es so funktioniert, wie es sollte, können Sie auf dem richtigen Weg iterieren.

Das Richtige ist wichtiger als der richtige Weg denke ich, solange man nicht freiwillig technische Schulden einführt. Und wie dazu? Das hängt von der Funktionalität und dem Team ab. Der richtige Weg bedeutet (für mich), dass der Code zum Zeitpunkt des Schreibens sauber, bei Bedarf dokumentiert und optimiert ist. Das Richtige zuerst zu bauen, kann jedes (ein anderes) dieser Dinge gefährden. Wenn Sie jedoch wissen, dass Sie das Richtige haben, wissen Sie, dass die Zeit, die benötigt wird, um es richtig zu machen, nicht verschwendet ist