@junit-team/junit-committers ada pemikiran tentang rilis 4.13? Sayangnya saya sangat sibuk dengan pekerjaan sehari-hari saya sehingga saya tidak dapat mengendarai rilis 4.13, tetapi saya pasti dapat membantu.

Saya telah mengaitkan beberapa masalah terbuka dengan Milestone 4.13 sebagai titik awal, tetapi tampaknya pencapaian tersebut tidak dapat memiliki utas komentar, jadi saya pikir kita dapat mendiskusikan penjadwalan dan fitur mana yang harus disertakan di sini

Satu hal yang ingin saya lakukan adalah menyelaraskan Assert.assertThrows / expectThrows dengan Assertions.assertThrows Jupiter. Saya tahu ada beberapa kontroversi di sekitar itu beberapa waktu lalu, tetapi sekarang setelah Jupiter dirilis, saya pikir kita harus mempertimbangkan skenario migrasi dan menghapus Assert.assertThrows dan mengganti nama expectThrows menjadi assertThrows . Ada keberatan?

Upaya terakhir untuk menghapus salah satunya adalah #1396

Saya dapat melihat kedua sisi perdebatan tentang penggabungan assertThrows dan expectThrows , jadi saya tidak akan keberatan dengan penarikan expectThrows dan memperbarui assertThrows untuk kembali pengecualian yang tertangkap. Saya sarankan untuk menjangkau orang-orang yang terlibat dalam tarikan asli dengan menambahkan metode ini ke 4.x, untuk memberi tahu mereka tentang penyelesaian masalah ini. Saya menyadari beberapa orang akan kecewa terlepas dari arah apa yang kami putuskan untuk ambil dengan API, tetapi tetap berpikir bahwa baik untuk memastikan semua orang tahu bahwa suara mereka didengar.

Sementara kami melakukannya, akan sangat bagus untuk mem-port assertThrows(Class<T> expectedType, Executable executable, String message) ke JUnit4 (lihat https://github.com/junit-team/junit5/commit/ea67ca0)

ada kemajuan pada rilis 4.13?

@zjffdu ya. Lihat https://github.com/junit-team/junit4/pulse/monthly untuk pekerjaan terbaru dan https://github.com/junit-team/junit4/milestone/3 untuk sisa pekerjaan yang diusulkan.

@kcooney
@marcphilipp
Sudah hampir 4 tahun setelah rilis terakhir 4.12.
Potong versi rilis 4.13-beta-1 untuk pengujian lebih dalam.

Saya (organisasi saya, sungguh) sangat ingin menggunakan pekerjaan yang telah dilakukan untuk TemporaryFolder (khususnya edisi #1223) jadi saya sangat tertarik untuk mendapatkan JUnit 4.13. Kami sedang mempertimbangkan untuk mengambil garpu proyek (pada 4.12), memilih perbaikan TemporaryFolder , dan menggunakan artefak JUnit yang dihasilkan dari itu hingga 4.13 benar-benar dirilis. (Belum mengevaluasi seberapa waras/gila itu.) Karena setidaknya beberapa proyek di mana kita akan menggunakan fork adalah proyek publik/OSS, artefak yang dihasilkan dari fork perlu dipublikasikan (di bawah a Grup Maven yang kami miliki) ke Maven Central. Tapi, jika Anda berencana untuk memotong 4.13 dalam waktu dekat, kita bisa menunggu. (Kami memiliki upaya yang sedang dilakukan untuk bermigrasi ke JUnit 5 tetapi itu belum membantu kami dengan TemporaryFolder .)

Pikiran?

Kami telah membangun dan menggunakan 4.13 apa adanya, dengan semua perubahannya, untuk sementara waktu sekarang, karena kami perlu memanfaatkan perbaikan bug. Belum melihat masalah apa pun sejauh ini.

@cljohnso menerbitkan versi JUnit Anda sendiri di Maven bisa menjadi masalah bagi beberapa pengguna Anda karena mereka kemungkinan akan bergantung pada versi resmi JUnit, dan memiliki kedua dependensi akan menghasilkan kelas duplikat di classpath, yang mengarah ke perilaku yang tidak terduga.

Sayangnya, JUnit dikelola oleh sukarelawan (banyak dari mereka mengerjakan JUnit 5) sehingga reless membutuhkan waktu lebih lama dari yang diperkirakan.

Salah satu cara untuk membantu kami bersiap adalah dengan memperbaiki dan meninjau catatan rilis. Banyak permintaan tarik tidak didokumentasikan di sana (lihat bug ini ).

Bug pemblokiran untuk 4.13 ada di sini .

Sepertinya semua masalah yang ditugaskan ke 4.13 telah diselesaikan.

@junit-team/junit-committers Apakah ada hal lain yang perlu ditangani sebelum merilis 4.13?

@marcphilipp Permintaan penarikan tertutup ini mungkin tidak didokumentasikan dalam catatan rilis: https://github.com/junit-team/junit4/issues?utf8= ✓&q=label%3A"needs+release+notes+update"+

Saya mulai menyelesaikan catatan rilis. Dalam melakukannya, saya membuat dua permintaan tarikan baru: #1551 dan #1552. Setidaknya #1552 harus di 4.13.

Halo semua,

Saya bertanya-tanya apakah ada yang punya timeline untuk rilis ini. Ada beberapa fitur yang saya harapkan untuk dimasukkan, dan bertanya-tanya apakah kita harus memasukkannya atau tidak.

Terima kasih untuk semua pekerjaan Anda!

@johnterrill Saya tidak berpikir kami berencana untuk menambahkan lebih banyak fitur baru ke 4.13 (hanya perbaikan bug)

Jika ada sesuatu yang ingin Anda tambahkan, jangan ragu untuk menambahkan permintaan fitur. Karena itu, hampir semua pengembangan fitur untuk JUnit terjadi di repositori junit5.

@kcooney Jika 4.13 hanya berisi perbaikan bug, ganti namanya menjadi 4.12.1 . Apakah masih ada pekerjaan yang sedang berlangsung?

Ini bukan hanya perbaikan bug, ada juga beberapa fitur baru, misalnya pemesanan. Jadi, saya pikir 4.13 masuk akal.

Masih ada 5 PR yang hilang dalam catatan rilis. Saya merawat mereka lusa ketika saya kembali ke Jerman. AFAIK hanya ini yang tersisa.

@marcphilipp Saya pikir kami siap untuk JUnit 4.13. Saya menyelesaikan catatan rilis.

Setelah #1568 dirilis dengan JUnit 4.13 akan menyenangkan (perlu tinjauan dari salah satu pengelola) tetapi itu tidak perlu.

Adakah pembaruan pada rilis 4.13? Saya sangat senang melihat rilis baru terjadi. :)

@robinyqiu
Saya ingat mereka berencana untuk menghentikan JUnit dan 4.13 harus menjadi versi terakhir. Karena ada 103 masalah terbuka dan beberapa permintaan tarik yang tertunda, versi tersebut harus melanjutkan pengembangan. Salah satu caranya adalah dengan memotong beberapa versi Release Candidate dan kita akan melihat apa yang akan terjadi dengan statistik mengenai jumlah bug dan pull request.

Saya yakin kami masih berencana untuk merilis 4.13 (karena banyaknya peningkatan dan perbaikan yang telah digabungkan).

Maaf, mengirimkan komentar terakhir itu sebelum saya menyelesaikan pemikiran saya.

Maaf bahwa ini memakan waktu cukup lama. Pengelola JUnit asli sibuk mendukung JUnit 5 atau telah mundur selangkah dari mengerjakan JUnit. Untuk alasan itu saya pikir kemungkinan 4.13 akan menjadi rilis terakhir jika baris kode 4.x.

@Tibor17 @kcooney Terima kasih atas tanggapan Anda! Apakah Anda memiliki perkiraan kasar kapan rilis 4.13 akan terjadi?

@robinyqiu Saya bukan pembuat komitmen tetapi kontributor lama.
@kcooney Saya pikir komunitas harus dengan jelas mempresentasikan rencana rilis untuk minggu atau bulan ke depan.

Saya masih yakin bahwa JUnit4 harus diselesaikan dengan masalah nol dan permintaan penarikan nol karena fakta bahwa seluruh dunia akan dan masih akan bergantung pada JUnit4 untuk waktu yang lama.
Jadi jika Anda melihat permintaan fitur apa pun, tutup permintaan tersebut dengan mengatakan bahwa kemungkinannya ada di JUnit5 dan tidak lagi di JUnit4.
Masalah yang menjadi milik kita harus diperbaiki dan permintaan tarik diterima. Permintaan tarikan lama terlihat bagi saya bahwa kami belum mencapai konsensus dengan orang yang membuat PR dan oleh karena itu mereka harus ditutup.

@Tibor17 Jika ada bug yang menurut Anda harus diperbaiki atau menarik permintaan yang harus diterima, silakan tambahkan komentar untuk masalah tersebut. Pada titik tertentu kami perlu memutuskan untuk memotong rilis untuk 4.13 (kami merilis 4.12 hampir empat tahun lalu).

Saya tidak yakin bagaimana perasaan saya tentang mengajukan kebangkrutan bug untuk JUnit 4.x. Saya tentu tidak punya waktu untuk melalui proses itu. Mungkin salah satu pengelola lain melakukannya.

@marcphilipp Apakah Anda punya waktu untuk memotong rilis 4.13? @kcooney , @dsaff ada keberatan?

@kcooney Ya, saya merasa ada masalah sejak 2015 hingga 2017 yang perlu ditutup. Ini akan menjadi langkah pertama yang harus dilakukan. Ini memberikan gambaran yang jelas dan sinyal kepada pengguna bahwa kami serius tidak akan melanjutkannya. Satu-satunya masalah yang tersisa perlu diselidiki kembali dan menghabiskan waktu hanya dengan itu. Dan kami akan kembali membersihkan tangan kami dan kami akhirnya dapat menyelesaikan proyek ini.

Apakah Anda punya waktu untuk memotong rilis 4.13?

Ya, saya bisa melakukannya di akhir pekan. Haruskah kita mengirimkan 4.13-RC1 atau 4.13-beta-1 terlebih dahulu?

4.13-beta-1 adalah ide yang bagus. Itu membuat skema penamaan rilis beta lama.

Berapa lama kita harus menunggu 4.13 setelah itu jika 4.13-beta-1 tidak ada masalah? 2 minggu?

Tidak ada keberatan untuk memotong rilis. Tidak ada pendapat yang kuat tentang RC1 vs beta-1.

4.13-beta-1 telah dirilis hari ini dan saya sekarang tersedia di Maven Central.

Terima kasih @marcphilipp !

Tampaknya Hamcrest akan merilis versi baru (lihat hamcrest/JavaHamcrest#224). Kandidat rilis sudah tersedia (https://github.com/hamcrest/JavaHamcrest/releases).

Akan sangat bagus jika ketergantungan pada Hamcrest dapat diperbarui untuk rilis baru. Apakah ini layak?

@BlueIce Terima kasih telah

Karena JUnit 4 masih kompatibel dengan Java 5, saya rasa kami tidak dapat mengupgrade ke Hamcrest 2.x karena memerlukan Java 7.

Saya bertanya-tanya apakah kita harus membuat ketergantungan kita pada Hamcrest optional di POM. Itu akan memaksa pengguna untuk membuat pilihan sadar apakah akan menggunakan Hamcrest dan, jika demikian, artefak dan versi mana.

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

Hai, pembuat Hamcrest di sini. Saat ini saya sedang mempersiapkan rilis 2.1 Hamcrest. Akan luar biasa jika ketergantungan Hamcrest dapat diperbarui. Saya baru saja merilis v2.1-rc3. Terlepas dari peningkatan nomor versi utama, rilis ini dimaksudkan untuk kompatibel dengan versi 1.3 (cerita panjang).

Satu hal yang perlu diperhatikan: di versi Hamcrest 2.1, kami telah mengubah cara pengemasan toples. hamcrest-core dan hamcrest-library telah digabungkan menjadi satu artefak: hamcrest (misalnya hamcrest-2.1.jar ). Untuk kompatibilitas mundur, kami masih merilis artefak hamcrest-core dan hamcrest-library versi 2.1, tetapi toples ini kosong, dan disediakan untuk menyederhanakan peningkatan melalui ketergantungan transitif pada hamcrest-2.1.jar .

Ketergantungan opsional juga akan berfungsi. Saya belum mencobanya, tetapi saya yakin jika Anda tidak menggunakan Assertions.assertThat(...) , Anda tidak memerlukan ketergantungan sama sekali? Jika Anda menggunakan matchers, maka secara eksplisit mendeklarasikan tergantung pada baik hamcrest-core-1.3.jar atau hamcrest-2.1.jar akan bekerja (saya belum diuji ini, meskipun!)

Preferensi pribadi saya: memiliki JUnit 4.13 bergantung langsung pada hamcrest-2.1.jar . Saya pikir ini akan menjadi jalur peningkatan yang paling tidak mengejutkan bagi kebanyakan orang.

@tumbarumba
Saya ingin menggunakan Java Hamcrest 2.1 tetapi itu tidak berarti bahwa saya ingin melihatnya di JUnit persis karena alasan kompatibilitas Java 1.5 seperti yang disebutkan @marcphilipp .
Menurut apa yang Anda sebutkan bahwa hamcrest-core sangat bergantung pada hamcrest tidak ada masalah bagi saya sebagai pengguna untuk menggunakan versi yang lebih tinggi di dependencyManagement dari POM saya. Pokoknya saya menggunakan hamcrest-library:1.3 dan mengubah versi menjadi 2.1 adalah apa yang harus saya lakukan, bukan masalah besar. Mungkin proyek JUnit5 dapat memikirkan tentang hamcrest:2.1 tapi itu cerita lain.

Ah, saya melewatkan poin tentang JUnit 4 yang kompatibel dengan Java 5. Tentu saja, ini berarti bahwa JUnit 4.x tidak dapat bergantung pada Hamcrest 2.0 atau lebih tinggi, setidaknya tidak secara langsung. JUnit 5 menghapus semua dependensi pada matcher pihak ketiga, dan sepenuhnya independen dari Hamcrest

Satu opsi: JUnit 4.13 menjaga ketergantungan pada Hamcrest 1.3. Jika ada yang ingin menggunakan fitur baru Hamcrest 2.1, mereka dapat secara eksplisit mendeklarasikan ketergantungan pada hamcrest-core-2.1.jar , yang akan memicu proses resolusi konflik versi, dan memutakhirkan pustaka (asalkan dideklarasikan terlebih dahulu).

Pilihan lain: gunakan atribut pom <optional> . Saya tidak punya banyak pengalaman dengan itu. Apakah mungkin untuk mendeklarasikan ketergantungan opsional pada hamcrest-core-1.3.jar dan hamcrest-2.1.jar . Apa yang terjadi dalam kasus itu?

@tumbarumba
Menggunakan ketergantungan optional hamcrest-2.1.jar di POM JUnit berarti bahwa pengguna tidak dapat mewarisinya ke POM-nya. Pada dasarnya, itu tidak akan menjadi ketergantungan transitif yang akan menjadi efek yang sama seperti tidak mendeklarasikan hamcrest-2.1.jar sama sekali.

Setelah merenungkan ini selama beberapa hari, saya sampai pada kesimpulan bahwa kita harus menjaga ketergantungan wajib pada hamcrest-core:1.3 untuk kompatibilitas mundur. Menjadikannya opsional akan lebih berbahaya daripada menguntungkan karena sebagian besar pengguna akan menambahkan ketergantungan lain.

Kami dapat menambahkan catatan ke catatan rilis yang menyebutkan Hamcrest 2.1. Selain itu, saya pikir itu akan menjadi ide yang baik untuk mendokumentasikan bagaimana menggunakan versi baru dengan JUnit 4.x dan alat-alat pembangunan yang berbeda di situs web atau wiki Hamcrest. Idealnya, kami dapat menautkan ke halaman ini dari catatan rilis JUnit 4.13.

@tumbarumba WDYT?

Saya setuju dengan kesimpulan Anda, @marcphilipp. Seperti yang sekarang saya pahami, ketergantungan JUnit 4 pada Java 1.5 sepenuhnya mengesampingkan Hamcrest 2.x, dan menggunakan dependensi opsional tidak akan berfungsi, sejauh yang saya bisa lihat.

Mengenai dokumen, saya memiliki permintaan tarik terbuka untuk memperbarui dokumentasi Hamcrest (lihat hamcrest/JavaHamcrest#237). Saya akan menghargai umpan balik tentang itu. Dokumen Hamcrest 2.1 dapat dipratinjau di https://tumbarumba.github.io/JavaHamcrest (dan khususnya catatan tentang Memutakhirkan dari Hamcrest 1.x ). Saya tidak akan menggabungkan permintaan tarik itu sampai rilis Hamcrest 2.1 yang sebenarnya.

Saya akan merilis kandidat rilis lain untuk Hamcrest 2.1 untuk memperbaiki beberapa masalah dengan kelas yang tidak digunakan lagi. Semoga ini menjadi RC yang terakhir (kecuali ada feedback lagi). Periksa hamcrest/JavaHamcrest#224 untuk mengikuti rilis Hamcrest berikutnya.

Sudah 3 minggu sejak 4.13-beta-1 dirilis. Adakah yang menghalangi rilis 4.13 final?

@ijuma https://github.com/junit-team/junit4/milestone/8 mencantumkan satu masalah

Kami mungkin menyertakan #1569

Saya pikir kita harus menyertakan #1569 dan merilis 4.13-beta-2. Saya membuat tonggak baru yang sesuai untuk mencerminkan hal itu.

Apakah ada berita kapan kita bisa berharap beta-2/GA akan dirilis? Saya sangat senang dengan 4.13 dan ingin menggunakannya secara nyata, tetapi tidak dapat menggunakannya dalam pekerjaan saya sehari-hari karena masih berstatus 'beta' :-(

Sekarang #1586 telah digabungkan, saya akan merilis 4.13-beta-2 dalam beberapa hari ke depan.

@junit-team/junit-committers Ada keberatan?

Tidak ada keberatan

4.13-beta-2 dirilis dan siap untuk diuji.

Sudah lebih dari sebulan sejak 4.13-beta-2 dan, sejauh yang saya ketahui, tidak ada laporan tentang masalah apa pun (kecuali untuk #1593). Saya mengusulkan kami merilis 4.13 dalam beberapa hari ke depan.

@junit-team/junit-committers Ada keberatan?

Kami telah menggunakan 4.13-beta-2 untuk Apache Kafka tanpa masalah.

@ijuma Terima kasih telah memberi tahu kami!

Tidak ada objek. Saya menggunakannya di tempat kerja dan semuanya berfungsi dengan baik.

Saya baru saja memulai proses menggunakan 4.13 di Google dan mengalami dua peringatan (yang dianggap sebagai kesalahan oleh sistem build kami) dan mengirimkan dua permintaan tarik. Saya mungkin mengalami lebih banyak masalah ketika saya mulai menjalankan banyak tes di bawah 4.13

Bisakah kita menunggu seminggu atau lebih?

Atau kita bisa menargetkan 13/4 ;-)

@kcooney Apakah saya benar bahwa dua PR yang Anda sebutkan adalah #1596 dan #1597? 4/13 terdengar seperti target yang sempurna :-)

Kedengarannya seperti validasi yang bagus, jadi mari kita tunggu hasilnya.

Fakta menyenangkan: 4.12 dirilis pada 12/4

@kcooney Apakah saya benar bahwa dua PR yang Anda sebutkan adalah #1596 dan #1597?

Ya.

Saya melihat regresi di DefaultInternalRunner di Mockito. Mengalami kesulitan mencari tahu apa yang sedang terjadi, tetapi masalahnya adalah testFinished dipanggil meskipun pengujiannya gagal. Namun, dari riwayat ParentRunner, saya tidak dapat menemukan masalah yang jelas.

Tes yang mundur pada 4.13 dan lolos pada 4.12 adalah https://github.com/mockito/mockito/blob/a323b8132de6f6e1c29d738de245469f8ce009b0/src/test/java/org/mockito/internal/runners/DefaultInternalRunnerTest.java#L42 -L59 I will lanjutkan debugging, tetapi petunjuk apa pun akan dihargai :senyum:

@TimvdLippe Javadoc untuk RunListener.testFinished() menyatakan:

"Dipanggil ketika tes atom telah selesai, apakah tes itu berhasil atau gagal." Saya tidak dapat menjelaskan mengapa Anda melihat perilaku yang berbeda antara 4.12 dan 4.13, tetapi perilaku yang Anda lihat untuk 4.13 terdengar seperti itu benar.

Saya ingin memperbarui perilaku sehingga berfungsi dengan baik dengan JUnit 4.13, meskipun saya khawatir kami dapat merusak integrasi JUnit 4.12 kami. Saya akan mencoba mencari solusi besok.

Saya dapat mengekstrak kotak reproduksi dari Mockito ke #1599. Tampaknya terkait dengan penanganan withBefores .

Saat saya menguji 4.13 di basis kode kami, #1421 menyebabkan beberapa masalah.

Adakah yang punya waktu untuk mengirimkan PR yang mengembalikan # 1421?

Selesai di #1602 oleh @panchenko.

@kcooney Haruskah kita melakukan rilis beta lagi?

@marcphilipp terserah anda. Perubahan terbaru seharusnya tidak memengaruhi orang-orang di 4.12 (hanya orang-orang di pra-rilis 4.13).

Dalam basis kode kami, saat ini saya sedang mengerjakan banyak tempat yang meneruskan null ke FrameworkMethod konstruktor yang sayangnya membuat sulit untuk melihat masalah sebenarnya.

@kcooney Bisakah Anda memperkirakan berapa banyak waktu yang Anda perlukan untuk melewati perubahan itu dan menjalankan uji coba terakhir?

@marcphilipp maaf atas keterlambatan balasan (saya sedang berlibur). Saat ini 2,9% pengujian kami gagal dengan JUnit 4.13, tetapi beberapa mungkin kegagalan yang tidak stabil. Sampel manual tidak menunjukkan masalah apa pun karena perubahan pada 4.13, tetapi saya masih harus melewati banyak hal.

@kcooney Jangan khawatir! Jadi, tidak ada perkiraan, kan? 😉

@marcphilipp Sejauh ini, kegagalan yang tersisa adalah tes yang telah melakukan hal-hal yang dipertanyakan, jadi saya tidak akan memblokir 4.13 pada itu. Aku akan melihat melalui semua kegagalan malam ini.

Beberapa contoh tes gagal karena melakukan hal-hal yang meragukan:

Kami memiliki beberapa tes bahwa subclass memiliki bidang @Rule yang nama dan jenisnya sama dengan bidang kelas dasar (yang juga dijelaskan dengan @Rule ). Rupanya di 4.12 Aturan subkelas akan dijalankan alih-alih aturan kelas dasar, tetapi di 4.13 keduanya dieksekusi. Saya ingat kami mengubah cara kerja anggota bayangan. Saya tidak ingat apakah yang saya lihat adalah perubahan yang disengaja.

Saya juga melihat kegagalan di mana JUnit 4.13 menghasilkan pesan kesalahan yang ditingkatkan, dan pengujiannya menegaskan pesan kesalahan tertentu.

(Diedit untuk memperbaiki nomor permintaan tarik)

@marcphilipp Saya mencoba mengingat mengapa saya membuat perubahan di #1414

Meskipun benar bahwa bidang tidak membayangi bidang yang sama dari kelas dasar, JUnit 4.x telah memperlakukannya seolah-olah untuk sementara waktu sekarang. Basis kode (sekali lagi, besar) yang saya kerjakan memiliki banyak contoh kode yang mengasumsikan bahwa bidang subkelas kelas @Rule akan menggantikan perilaku bidang kelas dasar. Meskipun tidak terlalu sulit untuk mengatasi masalah ini (ubah bidang menjadi metode, sehingga subkelas dapat menimpanya) saya bertanya-tanya apakah manfaat dari penarikan itu lebih besar daripada biaya untuk pengguna yang ada.

Saya pikir kita harus mengembalikannya dan mengembalikan yang lama, meskipun perilaku yang dipertanyakan untuk kompatibilitas mundur.

@stefanbirkner WDYT?

Saya setuju. Saya tidak melihat keuntungan yang membenarkan melanggar tes yang ada.

Saya membuat #1605 yang akhirnya mengembalikan #1414.

Saya pikir kita harus merilis rilis beta lainnya. @kcooney Haruskah saya melakukannya dalam beberapa hari ke depan atau apakah Anda menemukan masalah tambahan dengan 4.13-beta-2?

@marcphilipp Saya menambal dalam perubahan terbaru, dan sementara saya masih mencari melalui tayangan ulang, saya tidak melihat pola apa pun (selain tes yang menyatakan pesan kesalahan yang kami tingkatkan). Saya pikir masalah yang tersisa yang saya lihat adalah tes yang buruk atau terkelupas.

Maaf ini memakan waktu lama, tetapi saya senang kami mengembalikan perubahan itu!

4.13-beta-3 dirilis dan siap untuk diuji.

Akan sangat bagus jika salah satu dari Anda bisa bergabung di https://github.com/junit-team/junit4/pull/1608.

Saya juga akan berterima kasih jika Anda mempertimbangkan #1609.

Saya baru-baru ini memutakhirkan dari JUnit 4.12 ke JUnit 4.13-beta-3. Ini bekerja dengan baik.

Alasan saya memutakhirkan adalah karena saya membutuhkan perbaikan ini:
https://github.com/junit-team/junit4/commit/faa0e334080cd91f05fc1acbc7c39a525e172256

Adakah pemikiran tentang 4.13.0 GA?

@sullis Masalah utama yang tersisa adalah memperbaiki rekomendasi wrt. Hamcrest (lihat #1608).

Tim Hamcrest (alias saya) tidak berencana untuk membuat perubahan apa pun sehubungan dengan #1608. Apakah ini berarti tidak ada pemblokir lain untuk 4.13?

Saya tidak bermaksud kami menunggu tim Hamcrest untuk melakukan perubahan. Saya merujuk ke https://github.com/junit-team/junit4/pull/1608#issuecomment -496492379:

Singkatnya, seseorang perlu meninjau semua penghentian terkait Hamcrest dan memastikan bahwa "pesan penghentian" tidak menyarankan pengguna untuk menggunakan sesuatu yang sudah usang dan/atau tidak lagi tersedia.

Aku akan mengurus "pesan penghentian" mulai hari Rabu.

Aku akan mengurus "pesan penghentian" mulai hari Rabu.

Jika Anda menyelesaikannya pada Rabu malam, saya mungkin dapat memasukkannya ke dalam Spring Framework 5.2 GA , sehingga memungkinkan saya untuk mengembalikan komit ini https://github.com/spring-projects/spring-framework/commit/665e8aa51c11992909134d3ad5eebca6c94aa877.

Tapi... tidak ada tekanan. Secara resmi menyatakan bahwa Spring Framework 5.2 mendukung JUnit 4.13 hanya bagus untuk dimiliki. JUnit 4.13 masih akan berfungsi dengan baik dengan Spring 5.2 setelah JUnit 4.13 dirilis. 😉

Hai @sbrannen , saya mulai tetapi saya tidak menyelesaikannya malam ini. Saat ini saya membaca semua komentar dan mencoba memahami semua detailnya.

@stefanbirkner , jangan khawatir! Seperti yang saya katakan, itu akan "menyenangkan untuk dimiliki", tetapi tentu saja tidak ada persyaratan untuk itu. JUnit 4.13 masih berpotensi untuk dijemput secara resmi oleh Spring Boot 2.2. 😉

ada pemikiran tentang 4.13.0 GA?

Tanpa beberapa resolusi untuk #1609, JUnit 4.13 berisiko menjadi kurang relevan dari yang seharusnya. Pengguna JUnit 4.12 sedang menunggu perbaikan bug dan mungkin beberapa backport dari JUnit 5, bukan untuk penghentian kode yang tidak rusak.

apakah ada pemblokir untuk JUnit 4.13 GA?

Saya tidak melihat apapun. Saya akan menerbitkan 4.13-rc-1 untuk mendapatkan lebih banyak umpan balik tentang perubahan terbaru.

JUnit 4.13-rc-1 sekarang tersedia di Maven Central untuk pengujian! Harap beri tahu kami jika Anda mengalami masalah.

Diuji 4.13 beta dan rc dan berfungsi untuk kami di organisasi besar kami 👍

Saya menguji JUnit 4.13-rc1 dan saya tidak menemukan masalah apa pun.

Saya menguji JUnit 4.13-rc-1 dengan plugin Stash Pull Request Builder untuk Jenkins. Penghentian dipicu untuk file yang menggunakan ExpectedException sekali per file, seperti yang diharapkan.

Dalam banyak kasus, tes memeriksa jenis pengecualian, pesan, dan penyebabnya. Saya dapat memasukkan semua pemeriksaan ke dalam satu ekspresi untuk menghindari variabel sementara.

Saya tidak mendapatkan peringatan atau penolakan tentang kode baru dengan SpotBugs, sb-contrib, dan find-sec-bugs.

Satu-satunya ketidaksempurnaan kecil adalah bahwa cakupan untuk assertThat ditampilkan dengan warna kuning di Eclipse 2019-09 di Linux. Masih jauh lebih baik dari yang sebelumnya. Selain itu, tidak ada yang peduli tentang cakupan tes dari tes itu sendiri.

apa status JUnit 4.13?

Sudah tiga minggu sekarang dan hanya satu masalah yang dilaporkan: https://github.com/junit-team/junit4/issues/1636

@kcooney @stefanbirkner Bisa tolong lihat? Saya pikir kita bisa menutup masalah di atas.

@marcphilipp maaf atas keterlambatannya yang lama. Saya tidak punya banyak waktu untuk mengerjakan JUnit selama lebih dari setahun.

Saya mengomentari bug itu. Saya tidak melihat bagaimana kita bisa memperbaikinya.

Saya memang punya satu permintaan fitur untuk 4.13. Lihat #1637

Hai, apa status JUnit 4.13?

1637 diselesaikan dan saya akan merilis RC lain.

JUnit 4.13-rc-2 sekarang tersedia di Maven Central untuk pengujian! Harap beri tahu kami jika Anda mengalami masalah.

Saya menguji JUnit 4.13-rc2 dan saya tidak menemukan masalah apa pun. LGTM

Demikian juga, JUnit 4.13-rc-2 bekerja dengan benar untuk saya. Saya menggunakan pemeriksaan pengecualian baru.

apakah ada pemblokir untuk JUnit 4.13 GA?

@kcooney Bisakah Anda menguji ulang dengan 4.13-rc-2 sekarang setelah #1637 diselesaikan?

perubahan apapun?

apakah ada pemblokir untuk JUnit 4.13 GA?

Maaf atas jawaban yang terlambat; hal-hal telah sibuk beberapa minggu terakhir ini.

Saya tidak punya waktu untuk mengintegrasikan perubahan JUnit terbaru ke dalam kode kami
gudang. Saya memang melihat tes di pihak kami yang mencakup perilaku
pengacakan ketika kelas menggunakan FixMethodOrder, dan mereka terlihat hampir persis
sama seperti tes saya itu tarik saya. Saya tidak melihat alasan memblokir JUnit
rilis untuk melakukan lebih banyak verifikasi pada perbaikan itu.

q: apakah ada pemblokir untuk JUnit 4.13 GA?

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