@junit-team/junit-committers 4.13 릴리스에 대한 생각이 있습니까? 불행히도 나는 하루 일과가 너무 바빠서 4.13 릴리스를 운전할 수 없지만 확실히 도울 수는 있습니다.

Milestone 4.13과 관련된 몇 가지 미해결 문제를 출발점으로 삼았지만 이정표에는 주석 스레드가 없을 수 있으므로 일정 및 여기에 포함되어야 하는 기능에 대해 논의할 수 있다고 생각했습니다.

내가 하고 싶은 한 가지는 Assert.assertThrows / expectThrows 을 목성의 Assertions.assertThrows 맞추는 것입니다. 나는 주위에 약간의 논란이 있었다 알고 목성의 나는 우리가 마이그레이션 시나리오를 고려하고 제거해야한다고 생각 해제 된 것을 다시하면서하지만 지금은 Assert.assertThrows 하고 이름을 변경 expectThrows 에 assertThrows . 이의가 있으신가요?

그 중 하나를 제거하려는 마지막 시도는 #1396이었습니다.

assertThrows 및 expectThrows 병합에 대한 논쟁의 양면을 볼 수 있으므로 expectThrows 제거하고 assertThrows 를 업데이트하여 반환하는 것에 반대하지 않습니다. 잡힌 예외. 이 방법을 4.x에 추가하여 원래 풀에 관련된 사람들에게 연락하여 이 문제의 해결 방법을 알릴 것을 제안합니다. 우리가 API를 사용하기로 결정한 방향에 관계없이 일부 사람들이 화를 냈을 것이라는 것을 알고 있지만 여전히 모든 사람이 자신의 목소리가 들리고 있다는 사실을 알도록 하는 것이 좋다고 생각합니다.

그 동안 assertThrows(Class<T> expectedType, Executable executable, String message) 를 JUnit4로 이식하는 것이 좋습니다(https://github.com/junit-team/junit5/commit/ea67ca0 참조).

4.13 릴리스에 어떤 진전이 있습니까?

@zjffdu 네. 참조 https://github.com/junit-team/junit4/pulse/monthly을 최근의 일과에 대한 https://github.com/junit-team/junit4/milestone/3 제안 된 나머지 작업.

@kcooney
@marcphilipp
마지막 릴리스 4.12 이후 거의 4년이 지났습니다.
더 깊은 테스트를 위해 4.13-beta-1 릴리스 버전을 잘라냅니다.

나는(내 조직, 정말로) TemporaryFolder (특히 이슈 #1223)에 대해 수행된 작업을 사용하고 싶기 때문에 JUnit 4.13을 얻는 데 정말 관심이 있습니다. 우리는 프로젝트를 포크(4.12에서)하고, TemporaryFolder 수정 사항을 선별하고, 4.13이 실제로 릴리스될 때까지 여기에서 생성된 JUnit 아티팩트를 사용하는 것을 고려하고 있습니다. (아직 이것이 얼마나 정상적인지 평가하지 못했습니다.) 포크를 사용할 프로젝트 중 적어도 일부는 공개/OSS 프로젝트이므로 포크에서 생성된 아티팩트를 게시해야 합니다. 우리가 소유한 Maven 그룹)을 Maven Central로. 그러나 곧 4.13을 중단할 계획이라면 기다릴 수 있습니다. (JUnit 5로 마이그레이션하려는 노력이 진행 중이지만 TemporaryFolder 아직 도움이 되지 않습니다.)

생각?

버그 수정을 활용해야 했기 때문에 당분간 모든 변경 사항과 함께 4.13을 빌드하고 사용합니다. 지금까지 문제를 보지 못했습니다.

@cljohnso 자신의 JUnit 버전을 Maven에 게시하는 것은 일부 사용자에게 문제가 될 수 있습니다. 사용자가 JUnit의 공식 버전에 의존할 가능성이 높기 때문입니다. 두 종속성을 모두 갖는 경우 클래스 경로에 중복 클래스가 발생하여 예측할 수 없는 동작이 발생합니다.

불행히도 JUnit은 자원 봉사자(많은 사람들이 JUnit 5에서 작업함)에 의해 유지 관리되므로 예상보다 시간이 오래 걸립니다.

준비하는 데 도움이 되는 한 가지 방법은 릴리스 정보를 수정하고 검토하는 것입니다. 많은 pull 요청이 문서화되지 않았습니다( 이 버그 참조).

4.13 에 대한 차단 버그

4.13에 할당된 모든 문제가 해결된 것 같습니다.

@junit-team/junit-committers 4.13을 릴리스하기 전에 해결해야 할 다른 사항이 있습니까?

@marcphilipp 이러한 비공개 풀 요청은 릴리스 정보에 문서화되어 있지 않을 수 있습니다. https://github.com/junit-team/junit4/issues?utf8= ✓&q=label%3A"needs+release+notes+update"+

릴리스 노트를 완성하기 시작했습니다. 그 과정에서 두 개의 새로운 pull 요청인 #1551과 #1552를 만들었습니다. 최소한 #1552는 4.13에 있어야 합니다.

여러분 안녕하세요,

이 릴리스에 대한 일정이 있는 사람이 있는지 궁금합니다. 통합하기를 희망하는 몇 가지 기능이 있으며 이를 표로 작성해야 하는지 여부를 고민하고 있었습니다.

모든 작업에 감사드립니다!

@johnterrill 4.13에 더 이상 새로운 기능을 추가할 계획이 없다고 생각합니다(버그 수정만).

추가하고 싶은 기능이 있으면 언제든지 기능 요청을 추가해 주세요. 즉, JUnit의 거의 모든 기능 개발은 junit5 저장소에서 진행됩니다.

@kcooney 4.13 에 버그 수정만 포함되어 있으면 이름을 4.12.1 바꿉니다. 아직 진행중인 작업이 있나요?

버그 수정뿐만 아니라 주문과 같은 몇 가지 새로운 기능도 있습니다. 따라서 4.13이 의미가 있다고 생각합니다.

릴리스 정보에는 여전히 5개의 PR이 누락되어 있습니다. 나는 모레 독일에 돌아오면 그들을 돌본다. AFAIK 이것이 남은 전부입니다.

@marcphilipp JUnit 4.13을 사용할 준비가 되었다고 생각합니다. 릴리스 노트를 완성했습니다.

JUnit 4.13과 함께 #1568이 릴리스되면 좋겠지만(관리자 중 한 사람의 검토가 필요함) 꼭 필요한 것은 아닙니다.

4.13 릴리스에 대한 업데이트가 있습니까? 나는 새로운 릴리스가 일어나는 것을 보게 되어 매우 기쁩니다. :)

@robinyqu
나는 그들이 JUnit을 중단할 계획이었고 4.13이 마지막 버전이어야 했던 것을 기억합니다. 103개의 미해결 문제와 몇 가지 보류 중인 pull 요청이 있으므로 버전을 계속 개발해야 합니다. 한 가지 방법은 여러 릴리스 후보 버전을 잘라내는 것이며 버그 및 풀 리퀘스트 수에 관한 통계로 어떤 일이 일어날지 보게 될 것입니다.

우리는 여전히 4.13을 출시할 계획이라고 생각합니다(수많은 개선 사항 및 수정 사항이 병합되었기 때문에).

죄송합니다. 생각이 끝나기 전에 마지막 댓글을 제출했습니다.

시간이 오래 걸리는 점 사과드립니다. 원래 JUnit 유지 관리자는 JUnit 5를 지원하느라 바쁘거나 JUnit 작업에서 한 발 물러섰습니다. 이러한 이유로 4.x 코드 라인이라면 4.13이 마지막 릴리스가 될 가능성이 높다고 생각합니다.

@Tibor17 @kcooney 답변 감사합니다! 4.13 릴리스가 언제 나올지 대략적으로 예상하십니까?

@robinyqiu 저는 커미터는 아니지만 오랫동안 기여한 사람입니다.
@kcooney 커뮤니티에서 다음 주 또는 몇 달 동안의 출시 계획을 명확하게 제시해야 한다고 생각합니다.

전 세계가 JUnit4에 오랫동안 의존하고 있고 앞으로도 계속 그럴 것이기 때문에 JUnit4는 문제가 없고 pull 요청이 없는 상태로 마무리되어야 한다고 여전히 확신합니다.
따라서 기능 요청이 보이면 해당 요청이 JUnit5에 있고 더 이상 JUnit4에는 없을 것이라고 말하면서 닫으십시오.
우리의 문제는 수정되어야 하고 풀 리퀘스트가 받아들여져야 합니다. 오래된 pull 요청은 우리가 PR을 생성한 사람과 합의에 도달하지 못했기 때문에 닫아야 한다고 생각합니다.

@Tibor17 수정해야 할 버그가 있거나 수락해야 하는 pull 요청이 있는 경우 해당 문제에 대한 의견을 추가하세요. 어느 시점에서 우리는 4.13(우리는 거의 4년 전에 4.12를 릴리스)의 릴리스를 중단하기로 결정해야 합니다.

본질적으로 JUnit 4.x에 대한 버그 파산 신청에 대해 어떻게 느끼는지 잘 모르겠습니다. 나는 확실히 그 과정을 겪을 시간이 없습니다. 아마도 다른 유지 관리사 중 한 명이 그렇게 할 것입니다.

@marcphilipp 4.13 릴리스를 중단할 시간이 있습니까? @kcooney , @dsaff 이의가 있습니까?

@kcooney 예, 2015년부터 2017년까지 닫아야 할 문제가 있다고 생각합니다. 이것이 첫 번째 단계가 될 것입니다. 그것은 우리가 진지하게 그들을 계속하지 않을 것이라는 명확한 그림과 신호를 사용자에게 제공합니다. 남은 문제는 재조사하고 그 문제에만 시간을 할애해야 합니다. 그리고 우리는 다시 손을 씻고 마침내 프로젝트를 마칠 수 있습니다.

릴리스 4.13을 잘라낼 시간이 있습니까?

네, 주말에 할 수 있습니다. 먼저 4.13-RC1 또는 4.13-beta-1을 배송해야 합니까?

4.13-beta-1 좋은 생각입니다. 이전 베타 릴리스의 명명 체계를 유지합니다.

4.13-beta-1 에 문제가 없으면 4.13 이후에 얼마나 기다려야 합니까? 이주?

릴리스를 중단하는 데 이의가 없습니다. RC1 대 베타-1에 대한 강력한 의견이 없습니다.

4.13-beta-1이 오늘 출시되었으며 이제 Maven Central에서 사용할 수 있습니다.

@marcphilipp 감사

Hamcrest 가 새 버전을 출시할 예정인 것 같습니다(hamcrest/JavaHamcrest#224 참조). 릴리스 후보는 이미 사용 가능합니다(https://github.com/hamcrest/JavaHamcrest/releases).

Hamcrest에 대한 종속성이 새 릴리스에 대해 업데이트될 수 있다면 좋을 것입니다. 이것이 가능할까요?

@BlueIce 이 문제를

JUnit 4는 여전히 Java 5와 호환되므로 Java 7이 필요하기 때문에 Hamcrest 2.x로 업그레이드할 수 없다고 생각합니다.

하지만 POM에서 Hamcrest optional 에 대한 종속성을 만들어야 하는지 궁금합니다. 그러면 사용자는 Hamcrest를 사용할지, 그렇다면 어떤 아티팩트와 버전을 사용할지 의식적으로 선택해야 합니다.

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

안녕하세요, Hamcrest 커미터입니다. 저는 현재 Hamcrest의 2.1 릴리스를 준비하고 있습니다. Hamcrest 종속성을 업데이트할 수 있다면 굉장할 것입니다. 최근에 v2.1-rc3를 출시했습니다. 주 버전 번호의 증가에도 불구하고 이 릴리스는 1.3(긴 이야기)과 역호환되도록 의도되었습니다.

한 가지 알아야 할 사항: 버전 Hamcrest 2.1에서는 항아리가 패키징되는 방식이 변경되었습니다. hamcrest-core 및 hamcrest-library 가 단일 아티팩트 hamcrest (예: hamcrest-2.1.jar )로 병합되었습니다. 이전 버전과의 호환성을 위해 hamcrest-core 및 hamcrest-library 아티팩트의 2.1 버전을 계속 출시하고 있지만 이러한 항아리는 비어 있으며 hamcrest-2.1.jar 에 대한 전이 종속성을 통해 업그레이드를 단순화할 수 있도록 제공됩니다.

선택적 종속성도 작동합니다. 나는 그것을 시도하지 않았지만 Assertions.assertThat(...) 를 사용하지 않으면 의존성이 전혀 필요하지 않다고 생각합니다. 당신이 사용 매처 (Matchers)을 할 경우, 명시 적 중 하나에 따라 선언 hamcrest-core-1.3.jar 또는 hamcrest-2.1.jar 작동합니다 (I는하지만,이 테스트를하지 않은를!)

내 개인적인 취향: JUnit 4.13이 hamcrest-2.1.jar 에 직접 의존하도록 합니다. 나는 이것이 대부분의 사람들에게 가장 놀라운 업그레이드 경로가 될 것이라고 생각합니다.

@tumbarumba
Java Hamcrest 2.1을 사용하고 싶지만 @marcphilipp가 언급한 것처럼 Java 1.5의 호환성 이유 때문에 JUnit에서 정확히 보고 싶다는 의미는 아닙니다.
hamcrest-core 이 hamcrest 에 과도하게 의존한다고 언급한 것에 따르면 사용자로서 내 POM의 dependencyManagement 에서 더 높은 버전을 사용하는 데 문제가 없습니다. 어쨌든 나는 hamcrest-library:1.3 를 사용하고 있고 버전을 2.1 로 변경하는 것이 내가 해야 할 일이며 큰 문제는 아닙니다. JUnit5 프로젝트는 hamcrest:2.1 에 대해 생각할 수 있지만 그건 다른 이야기입니다.

아, JUnit 4가 Java 5와 호환된다는 요점을 놓쳤습니다. 물론 이것은 JUnit 4.x가 적어도 직접적으로는 아니더라도 Hamcrest 2.0 이상에 의존할 수 없다는 것을 의미합니다. JUnit 5는 타사 매처에 대한 모든 종속성을 제거했으므로 Hamcrest와 완전히 독립적입니다.

한 가지 옵션: JUnit 4.13은 Hamcrest 1.3에 대한 종속성을 유지합니다. 누구든지 Hamcrest 2.1의 새로운 기능을 사용하려는 경우 버전 충돌 해결 프로세스를 트리거하고 라이브러리를 업그레이드할 hamcrest-core-2.1.jar 에 대한 종속성을 명시적으로 선언할 수 있습니다(먼저 선언되는 한).

또 다른 옵션: pom <optional> 속성을 사용합니다. 나는 그것에 대한 경험이 많지 않습니다. hamcrest-core-1.3.jar 및 hamcrest-2.1.jar 모두에 대한 선택적 종속성을 선언할 수 있습니까? 그 경우에는 어떻게 됩니까?

@tumbarumba
JUnit의 POM에서 optional 종속성 hamcrest-2.1.jar 을 사용하면 사용자가 이를 POM으로 상속할 수 없습니다. 기본적으로 hamcrest-2.1.jar 를 전혀 선언하지 않는 것과 같은 효과가 있는 전이 종속성이 아닙니다.

이것을 며칠 동안 숙고한 결과, 하위 호환성을 위해 hamcrest-core:1.3 대한 필수 종속성을 유지해야 한다는 결론에 도달했습니다. 선택 사항으로 만드는 것은 대부분의 사용자가 다른 종속성을 추가해야 하기 때문에 득보다 실이 많을 것입니다.

Hamcrest 2.1을 언급하는 릴리스 정보에 메모를 추가할 수 있습니다. 또한, Hamcrest의 웹사이트나 위키에서 JUnit 4.x와 다른 빌드 도구와 함께 새 버전을 사용하는 방법을 문서화하는 것이 좋습니다. 이상적으로는 JUnit 4.13 릴리스 노트에서 이 페이지로 연결할 수 있습니다.

@tumbarumba WDYT?

@marcphilipp님의 결론에 동의합니다. 이제 내가 이해한 바에 따르면 Java 1.5에 대한 JUnit 4 종속성은 Hamcrest 2.x를 완전히 배제하고 선택적 종속성을 사용하는 것은 내가 볼 수 있는 한 작동하지 않습니다.

문서와 관련하여 Hamcrest 문서를 업데이트하기 위한 풀 요청이 열려 있습니다(hamcrest/JavaHamcrest#237 참조). 이에 대한 의견을 보내주시면 감사하겠습니다. Hamcrest 2.1 문서는 https://tumbarumba.github.io/JavaHamcrest (특히 Hamcrest 1.x 에서

더 이상 사용되지 않는 클래스의 일부 문제를 수정하기 위해 Hamcrest 2.1의 또 다른 릴리스 후보를 릴리스하려고 합니다. 이것이 마지막 RC가 되기를 바랍니다(더 이상의 피드백이 없는 한). 다음 Hamcrest 릴리스를 따르려면 hamcrest/JavaHamcrest#224를 확인하십시오.

4.13-beta-1이 출시된 지 3주가 지났습니다. 최종 4.13 릴리스를 차단하는 것이 있습니까?

@ijuma https://github.com/junit-team/junit4/milestone/8 은 한 가지 문제를 나열합니다.

#1569를 포함할 수 있습니다.

#1569를 포함하고 4.13-beta-2를 릴리스해야 한다고 생각합니다. 나는 그것을 반영하기 위해 새로운 해당 이정표를 만들었습니다.

베타-2/GA가 언제 출시되기를 희망할 수 있는지에 대한 소식이 있습니까? 4.13이 너무 좋아서 실제로 사용하고 싶지만 아직 '베타' 상태이기 때문에 일상 업무에서는 사용할 수 없습니다.:-(

이제 #1586이 병합되었으므로 앞으로 며칠 내에 4.13-beta-2를 릴리스하겠습니다.

@junit-team/junit-committers 이의가 있습니까?

이의 없음 😊

4.13-beta-2가 출시되어 테스트할 준비가 되었습니다.

4.13-beta-2 이후 한 달이 넘었고 내가 아는 한 문제에 대한 보고는 없었습니다(#1593 제외). 나는 우리가 앞으로 며칠 안에 4.13을 출시할 것을 제안하고 싶습니다.

@junit-team/junit-committers 이의가 있습니까?

Apache Kafka용 4.13-beta-2를 문제 없이 사용하고 있습니다.

@ijuma 알려 주셔서 감사합니다!

이의가 없습니다. 나는 직장에서 그것을 사용하고 있으며 모든 것이 잘 작동합니다.

방금 Google에서 4.13을 사용하는 프로세스를 시작했고 두 개의 경고(빌드 시스템에서 오류로 처리됨)가 발생했고 두 개의 풀 요청을 보냈습니다. 4.13에서 많은 테스트를 실행하기 시작하면 더 많은 문제가 발생할 수 있습니다.

일주일 정도 기다리면 될까요?

또는 4/13을 타겟팅할 수 있습니다. ;-)

@kcooney 말씀하신 2개의 PR이 #1596과 #1597인 것이 맞습니까? 4/13은 완벽한 목표처럼 들립니다 :-)

검증이 잘 된 것 같으니 결과를 기다리자.

재미있는 사실: 4.12가 12/4에 릴리스되었습니다 😉

@kcooney 말씀하신 2개의 PR이 #1596과 #1597인 것이 맞습니까?

예.

나는 Mockito의 DefaultInternalRunner 에서 회귀를 보고 있습니다. 무슨 일이 일어나고 있는지 파악하는 데 어려움이 있지만 문제는 테스트가 실패했음에도 불구하고 testFinished 가 호출된다는 것입니다. 그러나 ParentRunner의 역사에서 나는 어떤 명백한 문제도 발견할 수 없습니다.

4.13에서 회귀하고 4.12에서 통과하는 테스트는 https://github.com/mockito/mockito/blob/a323b8132de6f6e1c29d738de245469f8ce009b0/src/test/java/org/mockito/internal/runners/java 입니다. 디버깅을 계속하지만 포인터가 있으면 감사하겠습니다.

@TimvdLippe RunListener.testFinished() 대한 Javadoc 상태:

"테스트 성공 여부에 관계없이 원자성 테스트가 완료되면 호출됩니다." 4.12와 4.13 사이에 다른 동작이 나타나는 이유를 말할 수 없지만 4.13에 대해 보고 있는 동작이 올바른 것처럼 들립니다.

JUnit 4.12 통합이 깨질까 두렵긴 하지만 JUnit 4.13에서 제대로 작동하도록 동작을 업데이트하고 싶습니다. 내일 해결책을 찾아보도록 하겠습니다.

Mockito에서 #1599로 재생산 케이스를 추출할 수 있었습니다. withBefores 처리와 관련된 것 같습니다.

코드 기반에서 4.13을 테스트할 때 #1421이 몇 가지 문제를 일으키고 있습니다.

#1421로 되돌리는 PR을 제출할 시간이 있는 사람이 있습니까?

@panchenko가 #1602에 작성했습니다.

@kcooney 베타버전을

@marcphilipp 당신에게 달려 있습니다. 최근 변경 사항은 4.12의 사용자에게 영향을 미치지 않아야 합니다(4.13의 시험판 사용자에게만 해당).

우리의 코드 베이스에서 저는 현재 null 를 FrameworkMethod 생성자 🙄에 전달하는 많은 곳을 살펴보고 있습니다. 불행히도 실제 문제를 보기 어렵게 만듭니다.

@kcooney 이러한 변경 사항을 통과하고 최종 테스트를 실행하는 데 필요한 시간을 예상할 수 있습니까?

@marcphilipp 답장이 늦어서 죄송합니다(휴가 중이었습니다). 현재 테스트의 2.9%가 JUnit 4.13에서 실패하지만 일부는 일시적인 실패일 수 있습니다. 수동 샘플에서는 4.13의 변경으로 인해 문제가 표시되지 않지만 아직 해결해야 할 사항이 많습니다.

@kcooney 걱정마 ! 그래서, 견적이 없습니다, 그렇죠? 😉

@marcphilipp 지금까지 나머지 실패는 의심스러운 작업을 수행한 테스트이므로 4.13을 차단하지 않습니다. 오늘 밤 모든 실패를 살펴보겠다.

의심스러운 일을 하여 실패한 테스트의 몇 가지 예:

우리는 서브클래스에 기본 클래스 필드와 동일한 이름 및 유형인 @Rule 필드( @Rule 주석도 있음)가 있다는 몇 가지 테스트를 했습니다. 분명히 4.12에서는 하위 클래스 Rule이 기본 클래스 규칙 대신 실행되지만 4.13에서는 둘 다 실행됩니다. 섀도우 멤버의 작업 방식을 변경했던 것을 기억합니다. 내가 보고 있는 것이 의도적인 변화인지 기억이 나지 않습니다.

또한 JUnit 4.13이 개선된 오류 메시지를 생성하고 테스트에서 특정 오류 메시지를 표시하는 오류를 보고 있습니다.

(풀 리퀘스트 번호 수정을 위해 수정)

@marcphilipp #1414에서 변경한 이유를 기억하려고 합니다.

필드가 기본 클래스에서 동일한 필드를 섀도잉하지 않는 것은 사실이지만 JUnit 4.x는 이제 한동안 그러는 것처럼 처리했습니다. 내가 작업하고 있는 (대규모) 코드 기반에는 하위 클래스 클래스 @Rule 필드가 기본 클래스 필드의 동작을 대체한다고 가정하는 많은 코드 예제가 있습니다. 이 문제를 해결하는 것이 그리 어렵지는 않지만(필드를 메서드로 변경하여 하위 클래스가 재정의할 수 있음) 해당 풀의 이점이 기존 사용자의 비용보다 더 큰지 궁금합니다.

나는 우리가 그것을 되돌리고 이전 버전과의 호환성에 대한 의심스러운 동작이지만 이전을 복원해야 한다고 생각합니다.

@stefanbirkner WDYT?

나는 동의한다. 기존 테스트를 위반하는 것을 정당화할 수 있는 이점이 없습니다.

나는 마침내 # 1414로 돌아가는 # 1605를 만들었습니다.

다른 베타 버전을 출시해야 한다고 생각합니다. @kcooney 며칠 내로 그렇게 하시겠습니까? 아니면 4.13-beta-2에서 추가 문제를 발견하셨습니까?

@marcphilipp 최신 변경 사항에 패치를 적용했으며 여전히 재실행을 살펴보는 동안 패턴이 표시되지 않습니다(개선된 오류 메시지에 대해 주장하는 테스트 제외). 나는 내가보고있는 나머지 문제가 나쁘거나 불안정한 테스트라고 생각합니다.

너무 오래 걸려서 죄송하지만 변경 사항을 되돌려서 기쁩니다!

4.13-beta-3가 출시되어 테스트할 준비가 되었습니다.

여러분 중 한 명이 https://github.com/junit-team/junit4/pull/1608 에서 병합할 수 있다면 좋을 것

#1609도 고려해 주시면 감사하겠습니다.

최근에 JUnit 4.12에서 JUnit 4.13-beta-3으로 업그레이드했습니다. 그것은 잘 작동합니다.

업그레이드한 이유는 이 수정 사항이 필요했기 때문입니다.
https://github.com/junit-team/junit4/commit/faa0e334080cd91f05fc1acbc7c39a525e172256

4.13.0 GA에 대한 생각이 있으십니까?

@sullis 남은 주요 문제는 권장 사항을 수정하는 것입니다. 햄크레스트(#1608 참조).

Hamcrest 팀(일명 나)은 #1608과 관련하여 변경할 계획이 없습니다. 이것은 4.13에 대한 다른 차단기가 없다는 것을 의미합니까?

나는 우리가 Hamcrest 팀이 변화를 주기를 기다리고 있다는 뜻이 아닙니다. 나는 https://github.com/junit-team/junit4/pull/1608#issuecomment -496492379를 언급했습니다.

요약하면 누군가는 Hamcrest와 관련된 모든 사용 중단을 검토하고 "사용 중단 메시지"가 이미 사용되지 않거나 더 이상 사용할 수 없는 것을 사용하도록 사용자에게 조언하지 않는지 확인해야 합니다.

수요일부터 "지원 중단 메시지"를 처리하고 있습니다.

수요일부터 "지원 중단 메시지"를 처리하고 있습니다.

수요일 밤까지 완료하면 Spring Framework 5.2 GA 에 포함할 수 있으므로 이 커밋을 되돌릴 수 있습니다. https://github.com/spring-projects/spring-framework/commit/665e8aa51c11992909134d3ad5eebca6c94aa877.

하지만... 압박감은 없습니다. Spring Framework 5.2가 JUnit 4.13을 지원한다고 공식적으로 언급하는 것은 좋은 일입니다. JUnit 4.13이 릴리스되면 JUnit 4.13은 여전히 ​​Spring 5.2에서 제대로 작동합니다. 😉

안녕하세요 @sbrannen , 시작했지만 오늘 밤에 끝내지 못했습니다. 나는 현재 모든 댓글을 읽고 있으며 모든 세부 사항을 이해하려고 노력하고 있습니다.

@stefanbirkner , 걱정 마세요! 내가 말했듯이 "있으면 좋은" 것이지만 확실히 요구 사항은 없습니다. JUnit 4.13은 여전히 ​​잠재적으로 Spring Boot 2.2에서 공식적으로 채택될 시간이 있습니다. 😉

4.13.0 GA에 대한 생각이 있으신가요?

#1609에 대한 몇 가지 해결 방법이 없으면 JUnit 4.13이 실제보다 관련성이 떨어질 위험이 있습니다. JUnit 4.12 사용자는 버그 수정과 JUnit 5의 일부 백포트를 기다리고 있습니다. 손상되지 않은 코드의 사용 중단은 아닙니다.

JUnit 4.13 GA용 차단기가 있습니까?

나는 아무것도 보이지 않는다. 최신 변경 사항에 대한 추가 피드백을 얻기 위해 4.13-rc-1을 게시하겠습니다.

JUnit 4.13-rc-1은 이제 테스트를 위해 Maven Central에서 사용할 수 있습니다! 문제가 발생하면 알려주십시오.

4.13 beta 및 rc 테스트했으며 대규모 조직에서 작동합니다 👍

JUnit 4.13-rc1을 테스트했는데 문제가 발생하지 않았습니다.

Jenkins용 Stash Pull Request Builder 플러그인으로 JUnit 4.13-rc-1을 테스트했습니다. 예상대로 파일당 한 번 ExpectedException 사용하는 파일에 대한 지원 중단이 트리거되었습니다.

많은 경우 테스트에서 예외 유형, 메시지 및 원인을 확인했습니다. 임시 변수를 피하기 위해 모든 검사를 하나의 표현식에 맞출 수 있었습니다.

SpotBugs, sb-contrib 및 find-sec-bugs가 포함된 새 코드에 대한 경고나 사용 중단이 없습니다.

유일한 작은 결함은 assertThat 대한 적용 범위가 Linux의 Eclipse 2019-09에서 노란색으로 표시된다는 것입니다. 그래도 이전보다 훨씬 낫습니다. 게다가 아무도 테스트 자체의 테스트 커버리지에 신경 쓰지 않습니다.

JUnit 4.13의 상태는 무엇입니까?

이제 3주가 지났고 한 가지 문제만 보고되었습니다: https://github.com/junit-team/junit4/issues/1636

@kcooney @stefanbirkner 좀 봐주 시겠어요 ? 나는 우리가 위의 문제를 닫을 수 있다고 생각합니다.

@marcphilipp 오랜 지연에 대해 죄송합니다. 1년 넘게 JUnit을 작업할 시간이 많지 않았습니다.

나는 그 버그에 대해 논평했다. 어떻게 고칠 수 있는지 모르겠습니다.

4.13에 대한 기능 요청이 하나 있었습니다. #1637 참조

안녕하세요, JUnit 4.13의 상태는 어떻습니까?

1637이 해결되었고 다른 RC를 출시하겠습니다.

JUnit 4.13-rc-2는 이제 테스트를 위해 Maven Central에서 사용할 수 있습니다! 문제가 발생하면 알려주십시오.

JUnit 4.13-rc2를 테스트했는데 문제가 발생하지 않았습니다. LGTM

마찬가지로 JUnit 4.13-rc-2가 제대로 작동합니다. 새로운 예외 검사를 사용하고 있습니다.

JUnit 4.13 GA용 차단기가 있습니까?

@kcooney #1637이 해결

모든 업데이트?

JUnit 4.13 GA용 차단기가 있습니까?

늦은 답변 죄송합니다; 지난 몇 주 동안 일이 바빴습니다.

최신 JUnit 변경 사항을 코드에 통합할 시간이 없었습니다.
저장소. 나는 우리 측의 행동을 다루는 테스트를 살펴 보았습니다.
클래스가 FixMethodOrder를 사용하고 거의 정확하게 보일 때 무작위화
테스트와 동일합니다. JUnit을 차단할 이유가 없습니다.
해당 수정 사항에 대한 추가 확인 작업을 릴리스합니다.

q: JUnit 4.13 GA용 차단기가 있습니까?

JUnit 4.13이 출시되었습니다! 🎊
https://twitter.com/junitteam/status/1212403812192964608