@junit-team/junit-committers des réflexions sur une version 4.13 ? J'ai malheureusement été très occupé par mon travail quotidien, donc je ne peux pas piloter une version 4.13, mais je peux certainement aider.

J'ai associé quelques problèmes ouverts à Milestone 4.13 comme point de départ, mais il semble que les jalons ne peuvent pas avoir de fils de commentaires, j'ai donc pensé que nous pouvons discuter de la planification et des fonctionnalités à inclure ici

Une chose que je voudrais faire est d'aligner Assert.assertThrows / expectThrows avec les Assertions.assertThrows Jupiter. Je sais qu'il y a eu une controverse à ce sujet il y a quelque temps, mais maintenant que Jupiter est sorti, je pense que nous devrions envisager des scénarios de migration et supprimer Assert.assertThrows et renommer expectThrows en assertThrows . Des objections?

La dernière tentative pour supprimer l'un d'entre eux était le #1396

Je peux voir les deux côtés du débat sur la fusion de assertThrows et expectThrows , donc je ne m'opposerais pas à un pull supprimant expectThrows et mettant assertThrows jour

Pendant que nous y sommes, ce serait formidable de porter assertThrows(Class<T> expectedType, Executable executable, String message) vers JUnit4 (voir https://github.com/junit-team/junit5/commit/ea67ca0)

des progrès sur la version 4.13 ?

@zjffdu oui. Voir https://github.com/junit-team/junit4/pulse/monthly pour les travaux récents et https://github.com/junit-team/junit4/milestone/3 pour les travaux restants proposés.

@kcooney
@marcphilipp
Cela fait presque 4 ans après la dernière version 4.12.
Coupez la version 4.13-beta-1 pour des tests plus approfondis.

Je (mon organisation, vraiment) aimerait vraiment utiliser le travail qui a été fait pour TemporaryFolder (en particulier le numéro #1223) donc je suis vraiment intéressé à obtenir JUnit 4.13. Nous envisageons de prendre un fork du projet (à la 4.12), de choisir les correctifs TemporaryFolder et d'utiliser les artefacts JUnit générés à partir de cela jusqu'à la sortie de la 4.13. (Je n'ai pas encore évalué à quel point c'est sain d'esprit.) Étant donné qu'au moins certains des projets dans lesquels nous utiliserions le fork sont des projets publics/OSS, les artefacts produits à partir du fork devront être publiés (sous un groupe Maven que nous possédons) à Maven Central. Mais, si vous prévoyez de couper la 4.13 prochainement, nous pouvons simplement attendre. (Nous avons des efforts en cours pour migrer vers JUnit 5 mais cela ne nous aide pas encore avec TemporaryFolder .)

Les pensées?

Nous avons construit et utilisé la 4.13 telle quelle, avec toutes ses modifications, depuis un certain temps maintenant, car nous devions tirer parti d'une correction de bogue. Je n'ai vu aucun problème jusqu'à présent.

@cljohnso publier votre propre version de JUnit dans Maven pourrait être problématique pour certains de vos utilisateurs car ils dépendront probablement d'une version officielle de JUnit, et le fait d'avoir les deux dépendances entraînerait des classes en double sur le chemin de classe, ce qui entraînerait un comportement imprévisible.

Malheureusement, JUnit est entretenu par des bénévoles (dont beaucoup travaillent sur JUnit 5), donc les relâchements ont pris plus de temps que prévu.

Une façon de nous aider à nous préparer serait de corriger et de revoir les notes de version. De nombreuses demandes d'extraction n'y étaient pas documentées (voir ces bogues ).

Les bugs bloquants pour la 4.13 sont ici .

On dirait que tous les problèmes assignés à 4.13 ont été résolus.

@junit-team/junit-committers Y a-t-il autre chose à régler avant de publier la 4.13 ?

@marcphilipp Ces pull request fermées peuvent ne pas être documentées dans les notes de version : https://github.com/junit-team/junit4/issues?utf8= ✓&q=label%3A"needs+release+notes+update"+

J'ai commencé à compléter les notes de version. Ce faisant, j'ai créé deux nouvelles demandes d'extraction : #1551 et #1552. Au moins #1552 devrait être en 4.13.

Bonjour à tous,

Je me demandais si quelqu'un avait un calendrier pour cette version. Il y a certaines caractéristiques que j'espérais incorporer et je me demandais si nous devrions ou non le déposer.

Merci pour tout votre travail!

@johnterrill Je ne pense pas que nous

Si vous souhaitez ajouter quelque chose, n'hésitez pas à ajouter une demande de fonctionnalité. Cela étant dit, presque tous les développements de fonctionnalités pour JUnit se déroulent dans le référentiel junit5.

@kcooney Si 4.13 ne contient que des corrections de bogues, renommez-le en 4.12.1 . Y a-t-il encore des travaux en cours ?

Il ne s'agit pas seulement de corrections de bugs, il y a aussi quelques nouvelles fonctionnalités, par exemple la commande. Ainsi, je pense que 4.13 a du sens.

Il manque encore 5 PRs dans les notes de version. Je m'occupe d'eux après-demain quand je serai de retour en Allemagne. AFAIK c'est tout ce qui reste.

@marcphilipp Je pense que nous sommes prêts pour JUnit 4.13. J'ai terminé les notes de version.

Avoir #1568 publié avec JUnit 4.13 serait bien (il faudrait un avis de l'un des mainteneurs) mais ce n'est pas nécessaire.

Une mise à jour sur la version 4.13 ? Je suis très excité de voir la nouvelle version arriver. :)

@robinyqiu
Je me souviens qu'ils prévoyaient d'arrêter JUnit et que la 4.13 devait être la dernière version. Étant donné qu'il y a 103 problèmes ouverts et plusieurs demandes d'extraction en attente, les versions devraient continuer le développement. Une façon serait de couper plusieurs versions Release Candidate et nous verrons ce qui se passerait avec les statistiques concernant le nombre de bugs et de pull request.

Je pense que nous prévoyons toujours de publier la 4.13 (en raison du grand nombre d'améliorations et de correctifs qui ont été fusionnés).

Désolé, j'ai soumis ce dernier commentaire avant d'avoir terminé ma réflexion.

Désolé que cela prenne du temps. Les mainteneurs originaux de JUnit sont soit occupés à prendre en charge JUnit 5, soit ont pris du recul par rapport au travail sur JUnit. Pour ces raisons, je pense qu'il est probable que 4.13 sera la dernière version si la ligne de code 4.x.

@Tibor17 @kcooney Merci pour votre réponse ! Avez-vous une estimation approximative de la date de sortie de la version 4.13 ?

@robinyqiu Je ne suis pas un committer mais un contributeur de longue date.
@kcooney Je pense que la communauté devrait clairement présenter le plan de sortie pour les semaines ou les mois à venir.

Je suis toujours convaincu que JUnit4 devrait être finalisé avec zéro problème et zéro pull request en raison du fait que tout le monde est et dépendra encore longtemps de JUnit4.
Donc, si vous voyez des demandes de fonctionnalités, veuillez les fermer en disant que la possibilité serait dans JUnit5 et non plus dans JUnit4.
Les problèmes qui sont les nôtres doivent être résolus et les demandes de tirage acceptées. Les anciennes demandes de tirage me semblent que nous ne sommes pas parvenus à un consensus avec la personne qui crée le PR et qu'elles devraient donc être fermées.

@ Tibor17 S'il y a des bogues que vous pensez devoir être corrigés ou des demandes d'extraction qui devraient être acceptées, veuillez ajouter un commentaire à ces problèmes. À un moment donné, nous devons décider de couper une version pour la 4.13 (nous avons publié la 4.12 il y a presque quatre ans).

Je ne suis pas sûr de ce que je ressens à propos du dépôt de bilan de bogue pour JUnit 4.x. Je n'ai certainement pas le temps de suivre ce processus. Peut-être que l'un des autres mainteneurs le fait.

@marcphilipp Vous avez le temps de couper une release 4.13 ? @kcooney , @dsaff des objections ?

@kcooney Oui, je pense qu'il y a des problèmes entre 2015 et 2017 qui doivent être résolus. Ce serait la première étape à faire. Cela donne une image claire et un signal aux utilisateurs que nous ne les continuerons pas sérieusement. Les seuls problèmes restants doivent être réexaminés et passés du temps uniquement avec ceux-ci. Et nous nous laverons à nouveau les mains et nous pourrons enfin terminer le projet.

Avez-vous le temps de couper une version 4.13 ?

Oui, je peux le faire le week-end. Devrions-nous d'abord expédier une 4.13-RC1 ou une 4.13-beta-1 ?

4.13-beta-1 est une bonne idée. Il conserve le schéma de nommage des anciennes versions bêta.

Combien de temps devrions-nous attendre 4.13 après si 4.13-beta-1 n'a aucun problème ? 2 semaines?

Aucune objection à couper un communiqué. Pas d'opinion tranchée sur RC1 vs bêta-1.

La 4.13-beta-1 est sortie aujourd'hui et je suis désormais disponible sur Maven Central.

Merci @marcphilipp !

Il semble que Hamcrest soit sur le point de sortir une nouvelle version (voir hamcrest/JavaHamcrest#224). Les versions candidates sont déjà disponibles (https://github.com/hamcrest/JavaHamcrest/releases).

Ce serait formidable si la dépendance à Hamcrest pouvait être mise à jour pour la nouvelle version. Serait-ce faisable ?

@BlueIce Merci d'avoir attiré notre attention sur ce point !

Étant donné que JUnit 4 est toujours compatible avec Java 5, je pense que nous ne pouvons pas mettre à niveau vers Hamcrest 2.x car il nécessite Java 7.

Je me demande si nous devrions cependant rendre notre dépendance à Hamcrest optional dans le POM. Cela obligerait les utilisateurs à faire un choix conscient d'utiliser ou non Hamcrest et, le cas échéant, quel artefact et quelle version.

@tumbarumba @junit-team/junit-committers WDYT?

Salut, le committer Hamcrest ici. Je prépare actuellement la version 2.1 de Hamcrest. Ce serait génial si la dépendance Hamcrest pouvait être mise à jour. J'ai récemment publié la v2.1-rc3. Malgré l'augmentation du numéro de version majeur, cette version est destinée à être rétrocompatible avec la 1.3 (longue histoire).

Une chose à savoir : dans la version Hamcrest 2.1, nous avons changé la façon dont les pots sont empaquetés. hamcrest-core et hamcrest-library ont été fusionnés en un seul artefact : hamcrest (par exemple hamcrest-2.1.jar ). Pour une compatibilité descendante, nous publions toujours les versions 2.1 des artefacts hamcrest-core et hamcrest-library , mais ces jars sont simplement vides et sont fournis pour permettre de simplifier la mise à niveau via une dépendance transitive sur hamcrest-2.1.jar .

Une dépendance facultative fonctionnerait également. Je ne l'ai pas essayé, mais je pense que si vous n'utilisez pas Assertions.assertThat(...) , vous n'avez pas du tout besoin de la dépendance ? Si vous utilisez Matchers, puis déclarer explicitement une fonction soit hamcrest-core-1.3.jar ou hamcrest-2.1.jar travailleraient (je ne l' ai pas testé, mais!)

Ma préférence personnelle : faire en sorte que JUnit 4.13 dépende directement de hamcrest-2.1.jar . Je pense que ce serait le chemin de mise à niveau le moins surprenant pour la plupart des gens.

@tumbarumba
J'aimerais utiliser Java Hamcrest 2.1 mais cela ne veut pas dire que j'aimerais le voir dans JUnit exactement à cause des raisons de compatibilité de Java 1.5 comme l' a mentionné
D'après ce que vous avez mentionné, hamcrest-core est dépendant de hamcrest il n'y a aucun problème pour moi en tant qu'utilisateur à utiliser une version supérieure dans dependencyManagement de mon POM. Quoi qu'il en soit, j'utilise hamcrest-library:1.3 et changer la version en 2.1 est ce que je dois faire, ce n'est pas grave. Peut-être que le projet JUnit5 peut penser à hamcrest:2.1 mais c'est une autre histoire.

Ah, j'ai raté le fait que JUnit 4 soit compatible avec Java 5. Bien sûr, cela signifie que JUnit 4.x ne peut pas dépendre de Hamcrest 2.0 ou supérieur, du moins pas directement. JUnit 5 a supprimé toutes les dépendances sur les matchers tiers, et est donc complètement indépendant de Hamcrest

Une option : JUnit 4.13 garder la dépendance sur Hamcrest 1.3. Si quelqu'un souhaite utiliser les nouvelles fonctionnalités de Hamcrest 2.1, il peut déclarer explicitement une dépendance sur hamcrest-core-2.1.jar , ce qui déclenchera le processus de résolution des conflits de version et mettra à niveau la bibliothèque (tant qu'elle est déclarée en premier).

Autre option : utilisez l'attribut pom <optional> . Je n'ai pas beaucoup d'expérience avec ça. Est-il possible de déclarer une dépendance facultative à la fois sur hamcrest-core-1.3.jar et hamcrest-2.1.jar . Que se passe-t-il dans ce cas ?

@tumbarumba
L'utilisation optional dépendance hamcrest-2.1.jar dans le POM de JUnit signifie que l'utilisateur ne peut pas en hériter dans son POM. Fondamentalement, ce ne serait pas une dépendance transitive qui aurait le même effet que de ne pas déclarer du tout hamcrest-2.1.jar .

Après avoir réfléchi à cela pendant quelques jours, je suis arrivé à la conclusion que nous devrions conserver la dépendance obligatoire sur hamcrest-core:1.3 pour la compatibilité descendante. Le rendre facultatif ferait plus de mal que de bien car cela obligerait la plupart des utilisateurs à ajouter une autre dépendance.

Nous pouvons ajouter une note aux notes de version mentionnant Hamcrest 2.1. De plus, je pense que ce serait une bonne idée de documenter comment utiliser la nouvelle version avec JUnit 4.x et les différents outils de construction sur le site Web ou le wiki de Hamcrest. Idéalement, nous pourrions créer un lien vers cette page à partir des notes de version JUnit 4.13.

@tumbarumba WDYT?

Je suis d'accord avec ta conclusion, @marcphilipp. D'après ce que je comprends maintenant, la dépendance de JUnit 4 sur Java 1.5 exclut complètement Hamcrest 2.x, et l'utilisation de dépendances facultatives ne fonctionnera pas, d'après ce que je peux voir.

Concernant les docs, j'ai une pull request ouverte pour mettre à jour la documentation Hamcrest (voir hamcrest/JavaHamcrest#237). J'apprécierais tout commentaire à ce sujet. Les documents Hamcrest 2.1 peuvent être prévisualisés sur https://tumbarumba.github.io/JavaHamcrest (et en particulier la note sur la mise à

Je suis sur le point de publier une autre version candidate pour Hamcrest 2.1 afin de résoudre certains problèmes avec les classes dépréciées. Espérons que ce sera le dernier RC (à moins qu'il n'y ait plus de retours). Vérifiez hamcrest/JavaHamcrest#224 pour suivre la prochaine version de Hamcrest.

Cela fait 3 semaines que 4.13-beta-1 est sorti. Quelque chose bloque la version finale 4.13 ?

@ijuma https://github.com/junit-team/junit4/milestone/8 répertorie un problème

Nous pourrions inclure #1569

Je pense que nous devrions inclure #1569 et publier 4.13-beta-2. J'ai créé un nouveau jalon correspondant pour refléter cela.

Y a-t-il des nouvelles du moment où nous pouvons espérer la sortie de la bêta-2/GA ? Je suis tellement excité par 4.13 et j'ai hâte de l'utiliser pour de vrai, mais je ne peux pas l'utiliser dans mon travail quotidien car il a toujours le statut "bêta" :-(

Maintenant que #1586 a été fusionné, je publierai la 4.13-beta-2 dans les prochains jours.

@junit-team/junit-committers Des objections ?

Aucune objection 😊

La 4.13-beta-2 est publiée et prête à être testée.

Cela fait plus d'un mois depuis la version 4.13-beta-2 et, pour autant que je sache, aucun problème n'a été signalé (à l'exception de #1593). Je proposerais de sortir la 4.13 dans les prochains jours.

@junit-team/junit-committers Des objections ?

Nous utilisons la 4.13-beta-2 pour Apache Kafka sans aucun problème.

@ijuma Merci de nous l'avoir

Pas d'objections. Je l'utilise au travail et tout fonctionne bien.

Je viens de commencer le processus d'utilisation de la version 4.13 chez Google et j'ai rencontré deux avertissements (qui sont traités comme des erreurs par notre système de construction) et j'ai envoyé deux demandes d'extraction. Je pourrais rencontrer plus de problèmes lorsque je commencerai à exécuter de nombreux tests sous 4.13

Peut-on attendre une semaine environ ?

Alternativement, nous pourrions cibler le 13/04 ;-)

@kcooney Ai-je raison de dire que les deux PR que vous avez mentionnés sont #1596 et #1597 ? 4/13 sonne comme une cible parfaite :-)

Cela semble être une bonne validation, alors attendons les résultats.

Anecdote : la 4.12 est sortie le 4/12 😉

@kcooney Ai-je raison de dire que les deux PR que vous avez mentionnés sont #1596 et #1597 ?

Oui.

Je constate une régression de notre DefaultInternalRunner dans Mockito. J'ai du mal à comprendre ce qui se passe, mais le problème est que testFinished est appelé même si le test a échoué. Cependant, d'après l'histoire de ParentRunner, je ne peux repérer aucun problème évident.

Le test qui régresse sur 4.13 et passe sur 4.12 est https://github.com/mockito/mockito/blob/a323b8132de6f6e1c29d738de245469f8ce009b0/src/test/java/org/mockito/internal/runners/DefaultInternalRunnerTest.java I#L42 continuez le débogage, mais tous les pointeurs seraient appréciés :smile:

@TimvdLippe Le Javadoc pour RunListener.testFinished() indique :

"Appelé lorsqu'un test atomique est terminé, que le test réussisse ou échoue." Je ne peux pas expliquer pourquoi vous voyez un comportement différent entre 4.12 et 4.13, mais le comportement que vous voyez pour 4.13 semble correct.

J'aimerais mettre à jour le comportement afin qu'il fonctionne correctement avec JUnit 4.13, même si je crains que nous puissions casser notre intégration JUnit 4.12. J'essaierai de trouver une solution demain.

J'ai pu extraire un cas de reproduction de Mockito dans #1599. Cela semble être lié à la gestion de withBefores .

Alors que je teste la 4.13 dans notre base de code, #1421 pose quelques problèmes.

Quelqu'un a-t-il le temps de soumettre un PR qui revient au #1421 ?

Fait en #1602 par @panchenko.

@kcooney Devons-nous faire une autre version bêta ?

@marcphilipp à vous. Les changements récents ne devraient pas affecter les personnes sur 4.12 (seulement les personnes sur une préversion de 4.13).

Dans notre base de code, je travaille actuellement sur les nombreux endroits qui passent null au constructeur FrameworkMethod 🙄 ce qui rend malheureusement difficile de voir les vrais problèmes.

@kcooney Pouvez-vous estimer le temps dont vous aurez besoin pour effectuer ces changements et exécuter un test final ?

@marcphilipp désolé pour la réponse tardive (j'étais en vacances). Actuellement, 2,9% de nos tests échouent avec JUnit 4.13, mais certains peuvent être des échecs floconneux. Un échantillon manuel ne montre aucun problème en raison des modifications apportées à la version 4.13, mais j'en ai encore beaucoup à parcourir.

@kcooney Pas de soucis ! Donc pas d'estimation, non ? ??

@marcphilipp Jusqu'à présent, les échecs restants ont été des tests qui ont fait des choses discutables, donc je ne bloquerais pas 4.13 sur ceux-ci. J'examinerai tous les échecs ce soir.

Quelques exemples d'échecs de tests en raison de choses douteuses :

Nous avons quelques tests où une sous-classe a un champ @Rule qui est du même nom et du même type que le champ de la classe de base (qui est également annoté avec @Rule ). Apparemment, dans 4.12, la sous-classe Rule s'exécuterait à la place de la règle de classe de base, mais dans 4.13, les deux s'exécuteraient. Je me souviens que nous avons changé la façon dont les membres suivis travaillent. Je ne me souviens pas si ce que je vois était un changement intentionnel.

Je vois également des échecs où JUnit 4.13 produit des messages d'erreur améliorés, et les tests affirmaient un message d'erreur spécifique.

(Modifié pour corriger le numéro de demande de tirage)

@marcphilipp J'essaie de me rappeler pourquoi j'ai fait les changements dans #1414

S'il est vrai que les champs ne masquent pas le même champ de la classe de base, JUnit 4.x le traite comme s'ils le faisaient depuis un certain temps maintenant. La base de code (encore une fois, grande) sur laquelle je travaille contient de nombreux exemples de code qui supposent que les champs de la classe de sous-classe @Rule remplaceront le comportement des champs de la classe de base. Bien qu'il ne soit pas si difficile de contourner ce problème (changez les champs en méthodes, afin que les sous-classes puissent remplacer), je me demande si les avantages de cette extraction l'emportent sur les coûts pour les utilisateurs existants.

Je pense que nous devrions l'inverser et restaurer l'ancien comportement, bien que discutable, pour la compatibilité descendante.

@stefanbirkner WDYT ?

Je suis d'accord. Je ne vois aucun avantage qui justifie de casser les tests existants.

J'ai créé #1605 qui revient finalement à #1414.

Je pense que nous devrions sortir une autre version bêta. @kcooney Dois-je le faire dans les prochains jours ou avez-vous découvert des problèmes supplémentaires avec 4.13-beta-2 ?

@marcphilipp J'ai corrigé le dernier changement, et bien que je regarde toujours les rediffusions, je ne vois aucun modèle (autre que les tests affirmant les messages d'erreur que nous avons améliorés). Je pense que les problèmes restants que je vois sont des tests mauvais ou floconneux.

Désolé, cela a pris si longtemps, mais je suis heureux que nous ayons annulé ces changements !

4.13-beta-3 est disponible et prêt à être testé.

Ce serait formidable si l'un de vous pouvait fusionner dans https://github.com/junit-team/junit4/pull/1608.

Je vous serais également reconnaissant de considérer le #1609.

J'ai récemment mis à niveau de JUnit 4.12 à JUnit 4.13-beta-3. Cela fonctionne très bien.

La raison pour laquelle j'ai mis à niveau est que j'avais besoin de ce correctif :
https://github.com/junit-team/junit4/commit/faa0e334080cd91f05fc1acbc7c39a525e172256

Avez-vous une idée de la 4.13.0 GA ?

@sullis Le principal problème restant est de corriger les recommandations wrt. Hamcrest (voir #1608).

L'équipe Hamcrest (alias moi) n'a pas l'intention d'apporter de modifications par rapport à #1608. Cela signifie-t-il qu'il n'y a pas d'autres bloqueurs pour la 4.13 ?

Je ne voulais pas dire que nous attendions que l'équipe Hamcrest fasse des changements. Je faisais référence à https://github.com/junit-team/junit4/pull/1608#issuecomment -496492379 :

En résumé, quelqu'un doit examiner toutes les dépréciations concernant Hamcrest et s'assurer que le "message de dépréciation" ne conseille pas aux utilisateurs d'utiliser quelque chose qui est déjà obsolète et/ou n'est plus disponible.

Je m'occupe des "messages de dépréciation" à partir de mercredi.

Je m'occupe des "messages de dépréciation" à partir de mercredi.

Si vous le faites d'ici mercredi soir, je pourrais peut-être l'inclure dans Spring Framework 5.2 GA , me permettant ainsi d'annuler ce commit https://github.com/spring-projects/spring-framework/commit/665e8aa51c11992909134d3ad5eebca6c94aa877.

Mais... pas de pression. Déclarer officiellement que Spring Framework 5.2 prend en charge JUnit 4.13 n'est qu'une bonne chose. JUnit 4.13 fonctionnera toujours correctement avec Spring 5.2 une fois JUnit 4.13 publié. ??

Salut @sbrannen , j'ai commencé mais je ne le fais pas ce soir. Je lis actuellement tous les commentaires et essaie de comprendre tous les détails.

@stefanbirkner , pas de soucis ! Comme je l'ai dit, cela aurait été « bien d'avoir », mais il n'y a certainement aucune exigence pour cela. JUnit 4.13 a encore potentiellement le temps d'être récupéré officiellement par Spring Boot 2.2. ??

des pensées sur 4.13.0 GA?

Sans une certaine résolution pour #1609, JUnit 4.13 risque d'être moins pertinent qu'il ne pourrait l'être. Les utilisateurs de JUnit 4.12 attendent des corrections de bogues et éventuellement des rétroportages de JUnit 5, pas la dépréciation du code qui n'est pas cassé.

y a-t-il des bloqueurs pour JUnit 4.13 GA ?

Je n'en vois aucun. Je publierai une 4.13-rc-1 pour avoir plus de retours sur les derniers changements.

JUnit 4.13-rc-1 est maintenant disponible sur Maven Central pour les tests ! S'il vous plaît laissez-nous savoir si vous rencontrez des problèmes.

Testé 4.13 beta et rc et fonctionne pour nous dans notre grande organisation 👍

J'ai testé JUnit 4.13-rc1 et je n'ai rencontré aucun problème.

J'ai testé JUnit 4.13-rc-1 avec le plugin Stash Pull Request Builder pour Jenkins. Des dépréciations ont été déclenchées pour les fichiers utilisant ExpectedException une fois par fichier, comme prévu.

Dans de nombreux cas, les tests vérifiaient le type d'exception, le message et la cause. J'ai pu intégrer toutes les vérifications dans une seule expression pour éviter d'avoir une variable temporaire.

Je ne reçois aucun avertissement ou dépréciation concernant le nouveau code avec SpotBugs, sb-contrib et find-sec-bugs.

La seule petite imperfection est que la couverture pour assertThat est affichée en jaune dans Eclipse 2019-09 sous Linux. Encore bien mieux qu'avant. En outre, personne ne se soucie de la couverture des tests eux-mêmes.

quel est le statut de JUnit 4.13 ?

Cela fait maintenant trois semaines et un seul problème a été signalé : https://github.com/junit-team/junit4/issues/1636

@kcooney @stefanbirkner Pourriez-vous jeter un œil ? Je pense que nous pouvons clore le problème ci-dessus.

@marcphilipp désolé pour le long délai. Je n'ai pas eu beaucoup de temps pour travailler sur JUnit depuis plus d'un an.

J'ai commenté ce bug. Je ne vois pas comment on peut y remédier.

J'ai eu une demande de fonctionnalité pour 4.13. Voir #1637

Bonjour, quel est le statut de JUnit 4.13 ?

1637 a été résolu et je vais sortir un autre RC.

JUnit 4.13-rc-2 est maintenant disponible sur Maven Central pour les tests ! S'il vous plaît laissez-nous savoir si vous rencontrez des problèmes.

J'ai testé JUnit 4.13-rc2 et je n'ai rencontré aucun problème. LGTM

De même, JUnit 4.13-rc-2 fonctionne correctement pour moi. J'utilise les nouveaux contrôles d'exception.

y a-t-il des bloqueurs pour JUnit 4.13 GA ?

@kcooney Pourriez-vous s'il vous plaît re-tester avec 4.13-rc-2 maintenant que #1637 est résolu ?

toute mise à jour?

y a-t-il des bloqueurs pour JUnit 4.13 GA ?

Désolé pour la réponse tardive; les choses ont été chargées ces dernières semaines.

Je n'ai pas eu le temps d'intégrer les dernières modifications de JUnit dans notre code
dépôt. J'ai regardé les tests de notre côté qui couvrent le comportement de
randomisation lorsque les classes utilisent FixMethodOrder, et elles ressemblent presque exactement
le même que les tests que j'ai eu mon pull. Je ne vois pas de raison pour bloquer un JUnit
version sur faire plus de vérification sur ce correctif.

q : existe-t-il des bloqueurs pour JUnit 4.13 GA ?

JUnit 4.13 est disponible ! ??
https://twitter.com/junitteam/status/1212403812192964608