Testng: TestNG 7.3.0 memecah AssertJ berasumsiItu

Disebabkan oleh fee81b4f7ab48a84aad8da57f50739c8a8cec7e6 yang mengekspos kelas JUnit ke classpath runtime ( api ), alih-alih hanya menggunakannya untuk kompilasi ( compileOnly ).

Harap jangan mengekspos JUnit dan dependensi lainnya kecuali benar-benar diperlukan.

Karena kami akan segera merilis AssertJ versi 3.17.0, kami dapat memperkenalkan solusi di AssertJ untuk masalah ini, tetapi akan sangat bagus untuk mengetahui apakah TestNG memiliki rencana untuk mengatasinya.

Saya berharap kami bisa menggunakan org.opentest4j.TestSkippedException tetapi itu gagal dalam tes alih-alih melewatkannya.
Saya pikir cara terbaik ke depan adalah dengan mendefinisikan pengecualian umum di opentest4j untuk mengekspresikan melewatkan tes.

Pikiran?

Masalah ini harus diatasi di #2358.

@scordio - Saya tidak yakin apakah TestNG akan segera dirilis. Kami baru saja merilis 7.3.0 .

@cbeust @juherr -

TestNG seharusnya tidak mengekspos kelas JUnit secara default tetapi kelas TestNG dan JUnit tersedia saat fitur dukungan JUnit digunakan.

IMO, Ini harus diperbaiki di AssertJ terlebih dahulu dan tingkatkan dependensi TestNG secepatnya.

@krmahadevan @juherr sejauh yang saya mengerti, dependensi TestNG telah diperbaiki di #2358, yang sudah digabungkan. Apakah ini akan menjadi opsi untuk segera merilis versi perbaikan bug?

Tepatnya, di sisi AssertJ tidak ada yang salah saat ini. Kami memeriksa kelas mana yang ada di classpath untuk mendapatkan kerangka pengujian yang mendasarinya, dalam urutan berikut:

1. org.junit.AssumptionViolatedException (JUnit 4)
2. org.opentest4j.TestAbortedException (JUnit 5)
3. org.testng.SkipException (TestNG)

Lihat: https://github.com/joel-costigliola/assertj-core/blob/a36275ecd89ffa12cca931e65b3c9e4fa5322f7f/src/main/Java/org/assertj/core/api/Assumptions.java#L1295 -L1306

Karena TestNG mengekspos kelas JUnit 4 secara transitif, implementasi AssertJ saat ini mengasumsikan bahwa pengujian berjalan pada JUnit 4. Solusi yang saya usulkan akan memeriksa TestNG terlebih dahulu dan kemudian JUnit.

AssertJ 3.17.0 sudah keluar, tetapi kami mungkin akan segera merilis 3.17.1 karena masalah lain. Namun, memiliki rilis baru dari TestNG akan menjadi pilihan untuk mengatasi masalah ini.

Juga, seperti yang disebutkan oleh @joel-costigliola, akan menarik untuk mengetahui apakah ada rencana untuk mengadopsi opentest4j .

Terima kasih untuk detailnya.

Saya belum melihat darurat rilis TestNG.
Seperti yang saya katakan, memiliki JUnit dan TestNG di classpath adalah fitur, bukan praktik yang buruk.

Saya pikir logikanya sedikit lebih rumit:

• junit 4 + testng => mungkin testng dengan fitur junit
• junit 5 + testng => mungkin junit5 dengan https://github.com/testng-team/testng-junit5
• lainnya => logika saat ini

akan menarik untuk mengetahui apakah ada rencana untuk mengadopsi opentest4j.

Tidak ada rencana saat ini :(

@juherr maaf, saya salah memahami pesan Anda sebelumnya dan saya hanya fokus pada aspek ketergantungan transitif. Saya baru tahu sekarang bahwa kedua kerangka kerja bersama adalah kasus penggunaan yang tepat jika pengguna memutuskan untuk memiliki keduanya di classpath.

Saya kemudian akan mengubah urutan pemeriksaan AssertJ.

Tidak ada rencana saat ini :(

Apakah Anda tertarik dengan PR tentang hal itu?

@juherr @cbeust - Tautan https://github.com/ota4j-team/opentest4j#projects -already-contacted mengatakan TestNG telah dihubungi terkait hal ini. Apakah kalian sadar akan hal ini?

Saya tidak ingat melihat email apa pun tentang ini di daftar pengguna pengembang TestNG.

@scordio - Mungkin Anda dapat membuat PR (sehingga pekerjaan teknis yang terkait dengan bergerak ke arah ini akan dilakukan), tetapi kami perlu mendapatkan konfirmasi dari @cbeust tentang apa rencananya untuk ini.

@juherr - WDYT ?

Apakah kalian sadar akan hal ini?

Ya, kami dihubungi melalui surat bertahun-tahun yang lalu tetapi tanpa cukup waktu luang untuk berkontribusi.

@juherr - WDYT?

Itu menambah ketergantungan baru dan saya tidak yakin untuk memahami nilai tambah dari 6 kelas tetapi pada saat yang sama, itu bukan masalah besar jika itu dapat membantu seseorang.
Saya hanya ingin tahu apakah mungkin untuk menambahkan dukungan ke dalam kemasan independen tanpa over-engineering.

kita perlu mendapatkan konfirmasi dari @cbeust tentang apa rencananya untuk ini.

+1, saya membiarkan kata-kata terakhir untuk @cbeust

Saya baru saja memeriksa opentest4j dan proyek tersebut telah memiliki beberapa komit selama dua tahun terakhir, sehingga terlihat sangat mati. Apa keuntungan mendukungnya?

Saya pikir itu hanya sekelompok antarmuka/kelas abstrak, jadi seharusnya tidak perlu banyak pengembangan. Jika TestNG mengimplementasikan antarmuka tersebut/memperluas kelas tersebut, alat seperti AssertJ dapat menyederhanakan basis kode.

Saya baru saja memeriksa opentest4j dan proyek tersebut telah memiliki beberapa komit selama dua tahun terakhir, sehingga terlihat sangat mati. Apa keuntungan mendukungnya?

Saya tidak akan mengatakan itu mati, hanya saja tidak perlu banyak aktivitas.

Keuntungan utama yang saya lihat adalah dalam penanganan kasus-kasus yang disebutkan oleh @juherr :

Saya pikir logikanya sedikit lebih rumit:

* junit 4 + testng => maybe testng with the junit feature
* junit 5 + testng => maybe junit5 with https://github.com/testng-team/testng-junit5
* other => current logic

Memiliki pengecualian yang sama yang dilemparkan oleh TestNG dan JUnit akan menyederhanakan matriks dari semua kemungkinan kasus yang perlu ditangani oleh perpustakaan seperti AssertJ.

assertj-core 3.17.1 telah dirilis. Pengecualian TestNG sekarang lebih diutamakan daripada JUnit 4.

@C-Otto bisa tolong coba lagi dan beri tahu kami?

@scordio dikonfirmasi. Gagal dengan TestNG 7.3.0 dan AssertJ 3.17.0, diperbaiki dengan 7.3.0 / 3.17.1.

@C-Otto - Bisakah kita menutup masalah ini karena sekarang sudah ditangani di sisi AssertJ?