Ich baue gerade ein CI-Build-Skript für eine Legacy-Anwendung. Es gibt sporadische JUnit-Tests, und ich werde eine JUnit-Ausführung aller Tests in den CI-Build integrieren. Ich frage mich jedoch, was ich mit den 100-fachen Fehlern machen soll, denen ich in den nicht gepflegten JUnit-Tests begegne. Tu ich:
1) Kommentieren Sie sie aus, da sie eine vernünftige, wenn auch nicht geleistete Geschäftslogik in sich tragen, in der Hoffnung, dass jemand sie schließlich auskommentiert und repariert
2) Lösche sie, da es unwahrscheinlich ist, dass irgendjemand sie reparieren wird und der auskommentierte Code wird nur ignoriert oder für immer mehr Unordnung sein
3) Verfolgen Sie diejenigen, die dieses Durcheinander in meinen Händen hinterlassen haben, und schlagen Sie sie mit den Ausdrucken des Codes über den Köpfen (die aufgrund des langen Geruchs für die Aufgabe ausreichen) und predigen Sie die Vorteile eines gut gewartet und Unit-getestet Code-Basis
Wenn Sie Junit 4 verwenden, können Sie diese Tests mit @Ignore Annotation kommentieren.
Wenn Sie JUnit 3 verwenden, können Sie Tests einfach umbenennen, damit sie nicht mit test beginnen.
Versuchen Sie außerdem, die Tests für die von Ihnen geänderte Funktionalität zu korrigieren, um den Codefehler nicht zu vergrößern.
Die fehlgeschlagenen JUnit-Tests zeigen entweder
an In beiden Fällen müssen Sie die Tests / Quellen korrigieren / überprüfen. Da es so aussieht, als wäre es Ihre Aufgabe, das CI-System zu erstellen und die Tests nicht zu reparieren, würde ich in Ihrer Position eine Zeitbombe in den Tests hinterlassen. Sie können sehr geschickt mit annotierten Methoden mit JUnit 4 (etwas wie @IgnoreUntil(date="2010/09/16") ) und einem benutzerdefinierten Runner, oder Sie können einfach eine if-Anweisung in die erste Zeile jedes Tests hinzufügen:
Wo isBeforeTimeBomb() einfach das aktuelle Datum gegen ein zukünftiges Datum Ihrer Wahl überprüfen kann. Dann folgen Sie den Ratschlägen der anderen hier und benachrichtigen Sie Ihr Entwicklungsteam, dass der Build jetzt grün ist, aber in X Tagen explodieren wird, es sei denn, die TimeBombed-Tests sind behoben.
Folgen Sie der kein Fenster Prinzip gebrochen und nehmen eine Aktion zu einer Lösung von das Problem. Wenn Sie die Tests nicht reparieren können, mindestens:
Dann auf verhindern eine solche Situation in Zukunft geschieht, installieren Sie einen Stecker in ähnlich wie Hudson Game Plugin . Die Leute erhalten Punkte während der kontinuierlichen Integration, z.B.
Wirklich cooles Werkzeug, um Verantwortung über Unit Tests innerhalb eines Teams zu erstellen.
Wenn sie kompiliert werden, aber scheitern: Lassen Sie sie ein. Dadurch erhalten Sie im Laufe der Zeit eine gute Übersicht über Testverbesserungen, wenn Sie CI verwenden. Wenn die Tests nicht kompilieren, sondern den Build unterbrechen, kommentieren Sie sie aus und suchen Sie die Entwickler, um sie zu beheben.
Dies schließt natürlich nicht aus, die Option 3 zu verwenden (sie über den Kopf zu schlagen), Sie sollten dies trotzdem tun, unabhängig davon, was Sie mit den Tests machen.
Sie sollten sie auf jeden Fall vorläufig deaktivieren. Ob das durch Kommentieren, Löschen (vorausgesetzt, Sie können sie von der Quellcodeverwaltung zurückbekommen) oder andere Möglichkeiten ist Ihnen überlassen. Sie möchten nicht, dass diese fehlgeschlagenen Tests ein Hindernis für Personen darstellen, die versuchen, neue Änderungen zu übermitteln.
Wenn es genug wenige gibt, die du fühlst, kannst du sie selbst reparieren, großartig - tu es. Wenn es zu viele von ihnen gibt, würde ich geneigt sein, einen "Crowdsourcing" -Ansatz zu verwenden. Einen Fehler für jeden fehlgeschlagenen Test einreichen. Versuchen Sie, diese Fehler den tatsächlichen Besitzern / Autoren der Tests / des getesteten Codes zuzuordnen, wenn dies jedoch zu schwierig ist, dann ist die zufällige Auswahl in Ordnung, solange Sie den Leuten sagen, dass sie die Fehler, die ihnen falsch zugewiesen wurden, neu zuweisen. Ermutigen Sie dann die Leute, diese Fehler zu beheben, indem Sie ihnen entweder eine Frist setzen oder indem Sie regelmäßig alle über den Fortschritt informieren und sie ermutigen, alle Fehler zu beheben.
Ein CI-System, das ständig rot ist, ist ziemlich wertlos. Der Hauptvorteil besteht darin, einen Qualitätsbalken beizubehalten, und das wird viel schwieriger, wenn es keinen Übergang gibt, um einen Qualitätsabfall zu markieren.
Der sofortige Versuch sollte also sein, die fehlerhaften Tests zu deaktivieren und für jedes ein Tracking-Ticket / ein Workitem zu erstellen. Jeder von ihnen ist gelöst, aber Sie tun Triage - wenn sich niemand um den Test kümmert, werden Sie es loswerden. Wenn der Fehler ein Problem darstellt, das vor dem Versand behoben werden muss, lassen Sie den Test deaktiviert.
Sobald Sie sich in diesem Zustand befinden, können Sie sich darauf verlassen, dass das CI-System Ihnen sagt, dass dringende Maßnahmen erforderlich sind - machen Sie die letzte Änderung rückgängig oder setzen Sie sofort ein Team auf die Behebung des Problems oder was auch immer.
Ich kenne Ihre Position in der Firma nicht, aber wenn es möglich ist, lassen Sie die Probleme als Fehler in Ihrem Ticketsystem. Überlasse es den Entwicklern, sie entweder zu reparieren oder die Tests zu entfernen.
Wenn das nicht funktioniert, entferne sie (du hast die Versionskontrolle, richtig?) und schließe das Ticket mit einem Kommentar wie 'entfernte fehlgeschlagene Junit-Tests, die anscheinend nicht repariert werden' oder etwas Höflicheres.
Der Punkt ist, dass Junit-Tests Anwendungscode sind und als solche funktionieren sollten. Dafür werden Entwickler bezahlt. Wenn ein Test nicht mehr geeignet ist (etwas, das nicht mehr existiert, wurde getestet), sollten Entwickler dies signalisieren und den Test entfernen.
Tags und Links java continuous-integration legacy junit