@junit-team/junit-committers irgendwelche Gedanken zu einer Version 4.13? Leider war ich mit meinem Tagesjob sehr beschäftigt, daher kann ich kein 4.13-Release fahren, aber ich kann sicherlich helfen.

Ich habe als Ausgangspunkt einige offene Probleme mit Milestone 4.13 in Verbindung gebracht, aber es scheint, dass Meilensteine ​​keine Kommentarthreads haben können, also dachte ich, wir können die Planung besprechen und welche Funktionen hier enthalten sein sollten

Ich würde gerne Assert.assertThrows / expectThrows an Jupiters Assertions.assertThrows ausrichten. Ich weiß, dass es vor einiger Zeit einige Kontroversen darüber gab, aber jetzt, da Jupiter veröffentlicht wurde, sollten wir Migrationsszenarien in Betracht ziehen und Assert.assertThrows entfernen und expectThrows in assertThrows umbenennen. Irgendwelche Einwände?

Der letzte Versuch, eines davon zu entfernen, war #1396

Ich kann beide Seiten der Debatte über das Zusammenführen von assertThrows und expectThrows , also würde ich nichts dagegen haben, dass expectThrows und assertThrows aktualisiert wird, um zurückzukehren die gefangene Ausnahme. Ich schlage vor, die Leute zu kontaktieren, die an dem ursprünglichen Pull beteiligt waren, der diese Methoden zu 4.x hinzufügte, um sie über die Lösung dieses Problems zu informieren. Mir ist klar, dass einige Leute verärgert gewesen wären, unabhängig davon, welche Richtung wir mit den APIs eingeschlagen haben, aber ich denke immer noch, dass es gut ist, sicherzustellen, dass jeder weiß, dass seine Stimme gehört wird.

Wenn wir schon dabei sind, wäre es großartig, assertThrows(Class<T> expectedType, Executable executable, String message) auf JUnit4 zu portieren (siehe https://github.com/junit-team/junit5/commit/ea67ca0)

Gibt es Fortschritte bei der Version 4.13?

@zjffdu ja. Siehe https://github.com/junit-team/junit4/pulse/monthly für aktuelle Arbeiten und https://github.com/junit-team/junit4/milestone/3 für die vorgeschlagenen verbleibenden Arbeiten.

@kcooney
@marcphilipp
Es sind fast 4 Jahre seit der letzten Veröffentlichung 4.12 vergangen.
Cut 4.13-Beta-1-Release-Version für tiefere Tests.

Ich (meine Organisation, wirklich) würde gerne die Arbeit, die für TemporaryFolder geleistet wurde (insbesondere Ausgabe Nr. 1223) verwenden, also bin ich wirklich daran interessiert, JUnit 4.13 zu bekommen. Wir erwägen, einen Teil des Projekts (bei 4.12) zu nehmen, die TemporaryFolder Fixes herauszupicken und die daraus generierten JUnit-Artefakte zu verwenden, bis 4.13 tatsächlich veröffentlicht wird. (Habe noch nicht bewertet, wie vernünftig/wahnsinnig das ist.) Da zumindest einige der Projekte, in denen wir den Fork verwenden würden, öffentliche/OSS-Projekte sind, müssen die aus dem Fork erzeugten Artefakte veröffentlicht werden (unter a Maven-Gruppe, die wir besitzen) nach Maven Central. Wenn Sie jedoch vorhaben, 4.13 in Kürze zu kürzen, können wir einfach warten. (Wir haben Bemühungen im Gange, auf JUnit 5 zu migrieren, aber das hilft uns noch nicht mit TemporaryFolder .)

Die Gedanken?

Wir haben 4.13 so wie es ist, mit all seinen Änderungen, schon seit einiger Zeit gebaut und verwendet, weil wir einen Bugfix nutzen mussten. Habe bisher keine Probleme gesehen.

@cljohnso Das Veröffentlichen Ihrer eigenen Version von JUnit in Maven könnte für einige Ihrer Benutzer problematisch sein, da sie wahrscheinlich von einer offiziellen Version von JUnit abhängen und beide Abhängigkeiten zu doppelten Klassen im Klassenpfad führen würden, was zu unvorhersehbarem Verhalten führt.

Leider wird JUnit von Freiwilligen gewartet (von denen viele an JUnit 5 arbeiten), sodass die Freigabe länger gedauert hat als erwartet.

Eine Möglichkeit, uns bei der Vorbereitung zu unterstützen, besteht darin, die Versionshinweise zu korrigieren und zu überprüfen. Viele Pull-Requests wurden dort nicht dokumentiert (siehe diese Fehler ).

Die Blockierungsfehler für 4.13 sind da .

Es sieht so aus, als ob alle Probleme mit 4.13 behoben wurden.

@junit-team/junit-committers Gibt es noch etwas, das vor der Veröffentlichung von 4.13 angegangen werden muss?

@marcphilipp Diese geschlossenen Pull-Requests sind möglicherweise nicht in den Versionshinweisen dokumentiert: https://github.com/junit-team/junit4/issues?utf8= ✓&q=label%3A"needs+release+notes+update"+

Ich fing an, die Versionshinweise zu vervollständigen. Dabei habe ich zwei neue Pull Requests erstellt: #1551 und #1552. Mindestens #1552 sollte in 4.13 sein.

Hallo alle,

Ich habe mich gefragt, ob jemand einen Zeitplan für diese Veröffentlichung hat. Es gibt einige Funktionen, von denen ich gehofft hatte, sie zu integrieren, und fragte mich, ob wir sie anbieten sollten oder nicht.

Danke für deine ganze Arbeit!

@johnterrill Ich glaube nicht, dass wir geplant hatten, weitere neue Funktionen zu 4.13 hinzuzufügen (nur Fehlerbehebungen).

Wenn Sie etwas hinzufügen möchten, können Sie gerne eine Funktionsanfrage hinzufügen. Davon abgesehen findet fast die gesamte Funktionsentwicklung für JUnit im junit5-Repository statt.

@kcooney Wenn 4.13 nur Fehlerbehebungen enthält, benennen Sie es in 4.12.1 . Gibt es noch laufende Arbeiten?

Es sind nicht nur Bugfixes, es gibt auch ein paar neue Features, zB das Bestellen. Daher halte ich 4.13 für sinnvoll.

In den Release Notes fehlen noch 5 PRs. Ich kümmere mich übermorgen um sie, wenn ich wieder in Deutschland bin. AFAIK das ist alles was übrig bleibt.

@marcphilipp Ich denke, wir sind bereit für JUnit 4.13. Ich habe die Versionshinweise ausgefüllt.

Es wäre schön, #1568 mit JUnit 4.13 veröffentlicht zu haben (brauche eine Überprüfung von einem der Betreuer), aber es ist nicht notwendig.

Irgendein Update zur Version 4.13? Ich freue mich sehr, dass die neue Version erscheint. :)

@robinyqiu
Ich erinnere mich, dass sie geplant hatten, JUnit einzustellen und 4.13 die letzte Version sein musste. Da es 103 offene Probleme und mehrere ausstehende Pull-Requests gibt, sollten die Versionen weiterentwickelt werden. Eine Möglichkeit wäre, mehrere Release Candidate-Versionen zu kürzen und wir werden sehen, was mit den Statistiken bezüglich der Anzahl von Fehlern und Pull-Requests passiert.

Ich glaube, wir planen immer noch, 4.13 zu veröffentlichen (aufgrund der schieren Anzahl von Verbesserungen und Fixes, die zusammengeführt wurden).

Entschuldigung, ich habe den letzten Kommentar eingereicht, bevor ich meinen Gedanken beendet habe.

Entschuldigung, dass dies eine Weile dauert. Die ursprünglichen JUnit-Betreuer sind entweder damit beschäftigt, JUnit 5 zu unterstützen, oder haben sich von der Arbeit an JUnit zurückgezogen. Aus diesen Gründen halte ich es für wahrscheinlich, dass 4.13 die letzte Version der 4.x-Codezeile sein wird.

@Tibor17 @kcooney Danke für deine Antwort! Haben Sie eine ungefähre Schätzung, wann die Version 4.13 erscheinen wird?

@robinyqiu Ich bin kein Committer, sondern ein langjähriger Mitwirkender.
@kcooney Ich denke, die Community sollte den Releaseplan für die nächsten Wochen oder Monate klar präsentieren.

Ich bin immer noch davon überzeugt, dass JUnit4 ohne Probleme und ohne Pull-Request abgeschlossen werden sollte, da die ganze Welt lange Zeit von JUnit4 abhängig ist und sein wird.
Wenn Sie also Funktionsanfragen sehen, schließen Sie diese bitte mit dem Hinweis, dass die Möglichkeit dazu in JUnit5 und nicht mehr in JUnit4 besteht.
Probleme, die uns gehören, müssen behoben und Pull-Requests akzeptiert werden. Alte Pull-Requests sehen für mich so aus, dass wir mit der Person, die die PR erstellt hat, keinen Konsens erreicht haben und daher geschlossen werden sollten.

@Tibor17 Wenn es Fehler gibt, die Ihrer Meinung nach behoben werden müssen, oder Pull-Requests akzeptiert werden sollten, fügen Sie bitte einen Kommentar zu diesen Problemen hinzu. Irgendwann müssen wir uns entscheiden, eine Version für 4.13 zu veröffentlichen (wir haben 4.12 vor fast vier Jahren veröffentlicht).

Ich bin mir nicht sicher, was ich davon halten soll, für JUnit 4.x im Wesentlichen Bug-Insolvenz anzumelden. Ich habe sicherlich keine Zeit, diesen Prozess zu durchlaufen. Vielleicht tut es einer der anderen Betreuer.

@marcphilipp Hast du Zeit, eine Version 4.13 zu schneiden? @kcooney , @dsaff irgendwelche Einwände?

@kcooney Ja, ich habe das Gefühl, dass es seit 2015 bis 2017 Probleme gibt, die geschlossen werden müssen. Dies wäre der erste Schritt. Es gibt den Benutzern ein klares Bild und ein Signal, dass wir sie ernsthaft nicht fortsetzen werden. Die einzigen verbleibenden Probleme müssen erneut untersucht und Zeit nur mit diesen verbracht werden. Und wir werden uns wieder die Hände reinigen und wir können das Projekt endlich beenden.

Haben Sie Zeit, eine Version 4.13 zu schneiden?

Ja, das kann ich am Wochenende machen. Sollten wir zuerst eine 4.13-RC1 oder 4.13-Beta-1 ausliefern?

4.13-beta-1 ist eine gute Idee. Es behält das Namensschema der alten Beta-Versionen bei.

Wie lange sollten wir danach auf 4.13 warten, wenn 4.13-beta-1 keine Probleme hat? 2 Wochen?

Keine Einwände gegen eine Veröffentlichung. Keine starke Meinung zu RC1 vs. Beta-1.

4.13-beta-1 wurde heute veröffentlicht und ist jetzt auf Maven Central verfügbar.

Danke @marcphilipp !

Es scheint, dass Hamcrest im Begriff ist, eine neue Version zu veröffentlichen (siehe hamcrest/JavaHamcrest#224). Release-Kandidaten sind bereits verfügbar (https://github.com/hamcrest/JavaHamcrest/releases).

Es wäre toll, wenn die Abhängigkeit von Hamcrest für das neue Release aktualisiert werden könnte. Wäre dies machbar?

@BlueIce Danke, dass Sie uns darauf aufmerksam gemacht haben!

Da JUnit 4 immer noch mit Java 5 kompatibel ist, können wir meiner Meinung nach nicht auf Hamcrest 2.x aktualisieren, da es Java 7 erfordert.

Ich frage mich jedoch, ob wir unsere Abhängigkeit von Hamcrest optional im POM machen sollten. Dies würde die Benutzer zwingen, eine bewusste Entscheidung zu treffen, ob sie Hamcrest verwenden und wenn ja, welches Artefakt und welche Version.

@tumbarumba @

Hallo, Hamcrest Committer hier. Ich bereite derzeit die 2.1-Version von Hamcrest vor. Es wäre großartig, wenn die Hamcrest-Abhängigkeit aktualisiert werden könnte. Ich habe vor kurzem v2.1-rc3 veröffentlicht. Trotz der Erhöhung der Hauptversionsnummer soll diese Version abwärtskompatibel zu 1.3 sein (lange Geschichte).

Beachten Sie Folgendes: In Version Hamcrest 2.1 haben wir die Verpackung der Gläser geändert. hamcrest-core und hamcrest-library wurden zu einem einzigen Artefakt zusammengeführt: hamcrest (zB hamcrest-2.1.jar ). Aus Gründen der Abwärtskompatibilität veröffentlichen wir immer noch 2.1-Versionen der Artefakte hamcrest-core und hamcrest-library , aber diese Gläser sind nur leer und werden bereitgestellt, um das Upgrade durch eine transitive Abhängigkeit von hamcrest-2.1.jar zu vereinfachen

Eine optionale Abhängigkeit würde auch funktionieren. Ich habe es nicht versucht, aber ich glaube, wenn Sie Assertions.assertThat(...) nicht verwenden, brauchen Sie die Abhängigkeit überhaupt nicht? Wenn Sie Matchers tun, dann einen in Abhängigkeit von entweder explizit erklärt , hamcrest-core-1.3.jar oder hamcrest-2.1.jar funktionieren würde (ich nicht getestet haben, aber!)

Meine persönliche Präferenz: JUnit 4.13 hängt direkt von hamcrest-2.1.jar . Ich denke, dies wäre für die meisten Leute der am wenigsten überraschende Upgrade-Pfad.

@tumbarumba
Ich möchte Java Hamcrest 2.1 verwenden, aber das bedeutet nicht, dass ich es genau aus Kompatibilitätsgründen von Java 1.5 in JUnit sehen möchte, wie @marcphilipp erwähnt.
Nach dem, was Sie erwähnt haben, dass hamcrest-core trasitive von hamcrest abhängig ist, ist es für mich als Benutzer kein Problem, eine höhere Version in dependencyManagement meines POMs zu verwenden. Wie auch immer, ich benutze hamcrest-library:1.3 und die Änderung der Version auf 2.1 ist das, was ich tun muss, keine große Sache. Vielleicht kann das Projekt JUnit5 über hamcrest:2.1 nachdenken, aber das ist eine andere Geschichte.

Ah, ich habe den Punkt übersehen, dass JUnit 4 mit Java 5 kompatibel ist. Dies bedeutet natürlich, dass JUnit 4.x nicht von Hamcrest 2.0 oder höher abhängen kann, zumindest nicht direkt. JUnit 5 hat alle Abhängigkeiten von Matchern von Drittanbietern entfernt und ist somit völlig unabhängig von Hamcrest

Eine Möglichkeit: JUnit 4.13 behält die Abhängigkeit von Hamcrest 1.3 bei. Wenn jemand die neuen Funktionen von Hamcrest 2.1 verwenden möchte, kann er explizit eine Abhängigkeit von hamcrest-core-2.1.jar deklarieren, was den Lösungsprozess für Versionskonflikte auslöst, und die Bibliothek aktualisieren (sofern sie zuerst deklariert wird).

Eine andere Möglichkeit: Verwenden Sie das Attribut pom <optional> . Ich habe damit nicht viel Erfahrung. Ist es möglich, eine optionale Abhängigkeit von hamcrest-core-1.3.jar und hamcrest-2.1.jar zu deklarieren. Was passiert in diesem Fall?

@tumbarumba
Die Verwendung der optional Abhängigkeit hamcrest-2.1.jar im POM von JUnit bedeutet, dass der Benutzer sie nicht in sein POM vererben kann. Im Grunde wäre es keine transitive Abhängigkeit, die den gleichen Effekt hätte, als würde hamcrest-2.1.jar überhaupt nicht deklariert.

Nachdem ich einige Tage darüber nachgedacht habe, bin ich zu dem Schluss gekommen, dass wir die obligatorische Abhängigkeit von hamcrest-core:1.3 aus Gründen der Abwärtskompatibilität beibehalten sollten. Es optional zu machen, würde mehr schaden als nützen, da die meisten Benutzer eine weitere Abhängigkeit hinzufügen müssten.

Wir können den Versionshinweisen einen Hinweis hinzufügen, in dem Hamcrest 2.1 erwähnt wird. Außerdem halte ich es für eine gute Idee, die Verwendung der neuen Version mit JUnit 4.x und den verschiedenen Build-Tools auf Hamcrests Website oder Wiki zu dokumentieren. Idealerweise könnten wir aus den Versionshinweisen von JUnit 4.13 auf diese Seite verlinken.

@tumbarumba WDYT?

Ich stimme Ihrer Schlussfolgerung zu, @marcphilipp. Wie ich jetzt verstehe, schließt die JUnit 4-Abhängigkeit von Java 1.5 Hamcrest 2.x vollständig aus, und die Verwendung optionaler Abhängigkeiten wird, soweit ich sehen kann, nicht funktionieren.

In Bezug auf die Dokumente habe ich einen Pull-Request geöffnet, um die Hamcrest-Dokumentation zu aktualisieren (siehe hamcrest/JavaHamcrest#237). Ich würde mich über jedes Feedback dazu freuen. Die Hamcrest 2.1-Dokumentation kann unter https://tumbarumba.github.io/JavaHamcrest (und insbesondere der Hinweis zum Upgrade von Hamcrest 1.x ) in der Vorschau

Ich bin dabei, einen weiteren Release Candidate für Hamcrest 2.1 zu veröffentlichen, um einige Probleme mit veralteten Klassen zu beheben. Hoffentlich wird dies der letzte RC sein (es sei denn, es gibt noch mehr Feedback). Aktivieren Sie hamcrest/JavaHamcrest#224, um der nächsten Hamcrest-Version zu folgen.

Es ist 3 Wochen her, dass 4.13-beta-1 veröffentlicht wurde. Irgendetwas, das die endgültige Version 4.13 blockiert?

@ijuma https://github.com/junit-team/junit4/milestone/8 listet ein Problem auf

Wir könnten #1569 einschließen

Ich denke, wir sollten #1569 aufnehmen und 4.13-beta-2 veröffentlichen. Ich habe einen neuen entsprechenden Meilenstein geschaffen, um dies widerzuspiegeln.

Gibt es Neuigkeiten, wann wir auf die Veröffentlichung von Beta-2/GA hoffen können? Ich bin so begeistert von 4.13 und möchte es gerne wirklich nutzen, kann es aber nicht in meinem täglichen Job verwenden, da es noch 'Beta'-Status hat :-(

Nachdem #1586 zusammengeführt wurde, werde ich in den nächsten Tagen 4.13-beta-2 veröffentlichen.

@junit-team/junit-committers Irgendwelche Einwände?

Keine Einwände

4.13-beta-2 ist veröffentlicht und kann getestet werden.

Seit 4.13-beta-2 ist über einen Monat vergangen und, soweit mir bekannt ist, wurden keine Probleme gemeldet (außer Nr. 1593). Ich würde vorschlagen, dass wir in den nächsten Tagen 4.13 veröffentlichen.

@junit-team/junit-committers Irgendwelche Einwände?

Wir haben 4.13-beta-2 für Apache Kafka ohne Probleme verwendet.

@ijuma Danke, dass du uns Bescheid gegeben

Keine Einwände. Ich benutze es auf der Arbeit und alles funktioniert gut.

Ich habe gerade mit der Verwendung von 4.13 bei Google begonnen und bin auf zwei Warnungen gestoßen (die von unserem Build-System als Fehler behandelt werden) und habe zwei Pull-Requests gesendet. Ich könnte auf weitere Probleme stoßen, wenn ich viele Tests unter 4.13 starte

Können wir eine Woche oder so warten?

Alternativ könnten wir den 13.04. anvisieren ;-)

@kcooney Habe ich recht, dass die beiden von Ihnen erwähnten PRs #1596 und #1597 sind? 4/13 klingt nach einem perfekten Ziel :-)

Das klingt nach einer guten Bestätigung, also warten wir auf die Ergebnisse.

Fun Fact: 4.12 wurde am 04.12. veröffentlicht

@kcooney Habe ich recht, dass die beiden von Ihnen erwähnten PRs #1596 und #1597 sind?

Ja.

Ich sehe eine Regression in unserem DefaultInternalRunner in Mockito. Es fällt mir schwer herauszufinden, was los ist, aber das Problem ist, dass testFinished aufgerufen wird, obwohl der Test fehlgeschlagen ist. Aus der Geschichte von ParentRunner kann ich jedoch kein offensichtliches Problem erkennen.

Der Test, der auf 4.13 zurückfällt und auf 4.12 besteht, ist https://github.com/mockito/mockito/blob/a323b8132de6f6e1c29d738de245469f8ce009b0/src/test/java/org/mockito/internal/runners/DefaultInternalRunnerTest.ja I#L42 -L42 -L Fahren Sie mit dem Debuggen fort, aber für Hinweise wäre ich dankbar :smile:

@TimvdLippe Das Javadoc für RunListener.testFinished() besagt:

"Wird aufgerufen, wenn ein atomarer Test abgeschlossen ist, unabhängig davon, ob der Test erfolgreich ist oder fehlschlägt." Ich kann nicht sagen, warum Sie zwischen 4.12 und 4.13 ein unterschiedliches Verhalten sehen, aber das Verhalten, das Sie für 4.13 sehen, klingt so, als ob es richtig ist.

Ich würde das Verhalten gerne aktualisieren, damit es mit JUnit 4.13 richtig funktioniert, obwohl ich befürchte, dass wir unsere JUnit 4.12-Integration brechen könnten. Ich werde morgen versuchen eine Lösung zu finden.

Ich konnte einen Reproduktionskoffer von Mockito in #1599 extrahieren. Es scheint mit der Handhabung von withBefores .

Da ich 4.13 in unserer Codebasis teste, verursacht #1421 einige Probleme.

Hat jemand Zeit, eine PR einzureichen, die #1421 zurücksetzt?

Erstellt in #1602 von @panchenko.

@kcooney Sollen wir noch eine Beta-Version veröffentlichen?

@marcphilipp bis zu dir. Die letzten Änderungen sollten sich nicht auf die Version 4.12 auswirken (nur auf Personen mit einer Vorabversion von 4.13).

In unserer Codebasis arbeite ich gerade die vielen Stellen durch, die null an den FrameworkMethod Konstruktor übergeben 🙄 was es leider schwer macht die wirklichen Probleme zu erkennen.

@kcooney Können Sie abschätzen, wie viel Zeit Sie benötigen, um diese Änderungen zu durchlaufen und einen letzten Testlauf durchzuführen?

@marcphilipp sorry für die späte Antwort (ich war im Urlaub). Derzeit schlagen 2,9% unserer Tests mit JUnit 4.13 fehl, aber einige können flockige Fehler sein. Ein manuelles Beispiel zeigt aufgrund von Änderungen in 4.13 keine Probleme, aber ich muss noch viele durchgehen.

@kcooney Keine Sorge! Also keine Schätzung, oder? 😉

@marcphilipp Bisher waren die verbleibenden Fehler Tests, die fragwürdige Dinge

Einige Beispiele für Tests, die aufgrund fragwürdiger Dinge fehlschlagen:

Wir haben einige Tests durchgeführt, bei denen eine Unterklasse ein @Rule Feld hat, das denselben Namen und Typ hat wie das Basisklassenfeld (das auch mit @Rule annotiert ist). Anscheinend würde in 4.12 die Unterklasse Rule anstelle der Basisklassenregel ausgeführt, aber in 4.13 werden beide ausgeführt. Ich erinnere mich, dass wir die Arbeitsweise von Shadowed-Mitgliedern geändert haben. Ich kann mich nicht erinnern, ob das, was ich sehe, eine absichtliche Veränderung war.

Ich sehe auch Fehler, bei denen JUnit 4.13 verbesserte Fehlermeldungen erzeugt und die Tests eine bestimmte Fehlermeldung bestätigt haben.

(Bearbeitet, um die Pull-Request-Nummer zu korrigieren)

@marcphilipp Ich versuche mich zu erinnern, warum ich die Änderungen in #1414 vorgenommen habe

Es stimmt zwar, dass Felder nicht dasselbe Feld von der Basisklasse überschatten, aber JUnit 4.x behandelt dies schon seit einiger Zeit so, als ob sie es tun würden. Die (wiederum große) Codebasis, an der ich gerade arbeite, enthält viele Codebeispiele, die davon ausgehen, dass die Felder der Unterklassenklasse @Rule das Verhalten der Felder der Basisklasse ersetzen. Obwohl es nicht allzu schwer ist, dieses Problem zu umgehen (ändern Sie die Felder in Methoden, damit Unterklassen überschrieben werden können), frage ich mich, ob der Vorteil davon die Kosten für bestehende Benutzer überwiegt.

Ich denke, wir sollten es rückgängig machen und das alte, wenn auch fragwürdige Verhalten aus Gründen der Abwärtskompatibilität wiederherstellen.

@stefanbirkner WDYT?

Ich stimme zu. Ich sehe keinen Vorteil, der es rechtfertigt, bestehende Tests zu brechen.

Ich habe #1605 erstellt, was schließlich #1414 zurückgibt.

Ich denke, wir sollten eine weitere Beta-Version veröffentlichen. @kcooney Soll ich das in den nächsten Tagen machen oder hast du zusätzliche Probleme mit 4.13-beta-2 entdeckt?

@marcphilipp Ich habe die neueste Änderung gepatcht, und während ich immer noch Wiederholungen durchsuche, sehe ich keine Muster (außer Tests, die Fehlermeldungen bestätigen, die wir verbessert haben). Ich denke, die verbleibenden Probleme, die ich sehe, sind schlechte oder flockige Tests.

Es tut mir leid, dass es so lange gedauert hat, aber ich bin froh, dass wir diese Änderungen rückgängig gemacht haben!

4.13-beta-3 ist veröffentlicht und kann getestet werden.

Es wäre toll, wenn einer von euch https://github.com/junit-team/junit4/pull/1608 zusammenführen könnte.

Ich wäre Ihnen auch dankbar, wenn Sie #1609 in Betracht ziehen würden.

Ich habe vor kurzem ein Upgrade von JUnit 4.12 auf JUnit 4.13-beta-3 durchgeführt. Es funktioniert super.

Der Grund für das Upgrade ist, dass ich diesen Fix benötigte:
https://github.com/junit-team/junit4/commit/faa0e334080cd91f05fc1acbc7c39a525e172256

Irgendwelche Gedanken zu 4.13.0 GA?

@sullis Das verbleibende Hauptproblem besteht darin, die Empfehlungen bzgl. Hamcrest (siehe #1608).

Das Hamcrest-Team (auch bekannt als ich) plant keine Änderungen in Bezug auf #1608. Bedeutet dies, dass es keine anderen Blocker für 4.13 gibt?

Ich meinte nicht, dass wir darauf warten, dass das Hamcrest-Team Änderungen vornimmt. Ich bezog mich auf https://github.com/junit-team/junit4/pull/1608#issuecomment -496492379:

Zusammenfassend muss gesagt werden, dass jemand alle Einstellungen zu Hamcrest überprüfen und sicherstellen muss, dass die "Meldung zur Einstellung" Benutzer nicht dazu rät, etwas zu verwenden, das selbst bereits veraltet und/oder nicht mehr verfügbar ist.

Ich kümmere mich ab Mittwoch um die "Einstellungsmeldungen".

Ich kümmere mich ab Mittwoch um die "Einstellungsmeldungen".

Wenn Sie es bis Mittwochabend fertig haben, kann ich es möglicherweise in Spring Framework 5.2 GA aufnehmen , wodurch ich dieses Commit rückgängig machen kann https://github.com/spring-projects/spring-framework/commit/665e8aa51c11992909134d3ad5eebca6c94aa877.

Aber... kein Druck. Offiziell zu sagen, dass Spring Framework 5.2 JUnit 4.13 unterstützt, ist nur nett zu haben. JUnit 4.13 wird auch nach der Veröffentlichung von JUnit 4.13 problemlos mit Spring 5.2 funktionieren. 😉

Hallo @sbrannen , ich habe angefangen, aber ich

@stefanbirkner , keine Sorge! Wie gesagt, das wäre "nice to have" gewesen, aber es ist sicherlich keine Voraussetzung dafür. JUnit 4.13 hat möglicherweise noch Zeit, offiziell von Spring Boot 2.2 abgeholt zu werden. 😉

Irgendwelche Gedanken zu 4.13.0 GA?

Ohne eine Auflösung für #1609 besteht die Gefahr, dass JUnit 4.13 weniger relevant ist, als es sein könnte. Benutzer von JUnit 4.12 warten auf Bugfixes und möglicherweise einige Backports von JUnit 5, nicht auf die Veraltung des Codes, der nicht kaputt ist.

Gibt es Blocker für JUnit 4.13 GA?

Ich sehe keine. Ich werde eine 4.13-rc-1 veröffentlichen, um mehr Feedback zu den neuesten Änderungen zu erhalten.

JUnit 4.13-rc-1 ist jetzt auf Maven Central zum Testen verfügbar! Bitte teilen Sie uns mit, wenn Probleme auftreten.

Getestet 4.13 beta und rc und funktioniert für uns in unserer großen Organisation 👍

Ich habe JUnit 4.13-rc1 getestet und bin auf keine Probleme gestoßen.

Ich habe JUnit 4.13-rc-1 mit dem Stash Pull Request Builder-Plugin für Jenkins getestet. Für Dateien, die ExpectedException einmal pro Datei verwenden, wurden erwartungsgemäß Verwerfungen ausgelöst.

In vielen Fällen prüften die Tests den Ausnahmetyp, die Meldung und die Ursache. Ich war in der Lage, alle Prüfungen in einen Ausdruck zu integrieren, um eine temporäre Variable zu vermeiden.

Ich erhalte keine Warnungen oder Verwerfungen über den neuen Code mit SpotBugs, sb-contrib und find-sec-bugs.

Der einzige kleine Fehler ist, dass die Abdeckung für assertThat in Eclipse 2019-09 unter Linux gelb angezeigt wird. Immer noch viel besser als das, was vorher war. Außerdem kümmert sich niemand um die Testabdeckung der Tests selbst.

Wie ist der Stand von JUnit 4.13?

Es ist jetzt drei Wochen her und nur ein Problem wurde gemeldet: https://github.com/junit-team/junit4/issues/1636

@kcooney @stefanbirkner Könnten Sie bitte einen Blick darauf werfen? Ich denke, wir können das obige Problem schließen.

@marcphilipp Entschuldigung für die lange Verzögerung. Ich hatte seit über einem Jahr nicht viel Zeit, an JUnit zu arbeiten.

Ich habe diesen Fehler kommentiert. Ich sehe nicht, wie wir das beheben können.

Ich hatte eine Funktionsanfrage für 4.13. Siehe #1637

Hallo, wie ist der Status von JUnit 4.13?

1637 wurde gelöst und ich werde ein weiteres RC veröffentlichen.

JUnit 4.13-rc-2 ist jetzt auf Maven Central zum Testen verfügbar! Bitte teilen Sie uns mit, wenn Probleme auftreten.

Ich habe JUnit 4.13-rc2 getestet und bin auf keine Probleme gestoßen. LGTM

Ebenso funktioniert JUnit 4.13-rc-2 bei mir korrekt. Ich verwende die neuen Ausnahmeprüfungen.

Gibt es Blocker für JUnit 4.13 GA?

@kcooney Könnten Sie bitte erneut mit 4.13-rc-2 testen, jetzt, da #1637 gelöst ist?

irgendein Update?

Gibt es Blocker für JUnit 4.13 GA?

Entschuldigung für die späte Antwort; In den letzten Wochen war viel los.

Ich hatte keine Zeit, die neuesten JUnit-Änderungen in unseren Code zu integrieren
Repository. Ich habe mir die Tests auf unserer Seite angeschaut, die das Verhalten von
Randomisierung, wenn Klassen FixMethodOrder verwenden, und sie sehen fast genau aus
genauso wie bei den tests hatte ich es meinen zug. Ich sehe keinen Grund, einen JUnit zu blockieren
release auf weitere Überprüfungen für diesen Fix.

F: Gibt es Blocker für JUnit 4.13 GA?

JUnit 4.13 ist erschienen! 🎊
https://twitter.com/junitteam/status/1212403812192964608