Konvensi penamaan untuk paket pengujian


11

Kami sebenarnya menamai paket pengujian kami seperti rekan-rekan mereka untuk menguji. Jadi kita berakhir dengan struktur ini:

src/main/java
    com.hello.world
        helloWorld.java
src/test/java
    com.hello.world
        helloWorldTest.java

Saya selalu merasa bahwa ini tidak cukup pintar karena Anda tidak dapat membedakan antara "test" dan "to-test" jika hanya disediakan dengan nama paket. Di sisi lain saya belum benar-benar menemukan kasus di mana ini penting entah bagaimana. Apakah praktik yang baik untuk memiliki konvensi penamaan yang sama untuk kedua paket (untuk kasus uji dan kelas sumber)? Jika tidak, apa yang akan menjadi pendekatan yang lebih baik?


1
Tidak tahu apakah itu praktik yang baik, tapi ini yang populer. Pilihan lain (untuk memasukkan "Test" ke dalam nama paket, nama metode dll) sedikit banyak menampar "Penamaan Smurf". Seperti yang Anda katakan, sulit untuk memikirkan kasus di mana tidak dapat "membedakan antara" test "dan" to-test "jika hanya disediakan dengan nama paket" akan menjadi masalah.
David Arno

@ Davidvidno Terima kasih atas masukan Anda :) Bagaimana cara menghindari penamaan smurf? Maksudku, kita akan berakhir dengan com.hello.world.test.helloWorld.java, bukan?
OddDev

Masalah "smurf" lebih ketika Anda memiliki metode XXXTest()dalam com.hello.world.test.helloWorldTest.java. Nasihat umum akan hanya memiliki "Tes" muncul sekali di jalan, sehingga (a) menggunakan tes dalam nama paket (dan beri nama file uji sama dengan file yang diuji) atau (b) buat nama paket sebagai sama dan tambahkan "test" ke nama file / kelas.
David Arno

@ David Arno Ah, terima kasih atas klarifikasi! Saya salah komentar pertama. Aku mengerti sekarang.
OddDev

Yah saya berpendapat bahwa, jika tidak jelas, saya mendapat komentar pertama saya salah :)
David Arno

Jawaban:


11

Itu adalah konvensi yang bagus.

Kadang-kadang Anda ingin menulis tes unit untuk kelas dan metode paket-pribadi juga. Anda tidak akan dapat memanggil mereka dari kelas unit test yang ditempatkan dalam paket lain.

Seharusnya tidak ada kebingungan tentang memiliki kelas unit test di namespace yang sama karena mereka seharusnya tidak berada di jalur kelas ketika mengkompilasi atau menjalankan kode produksi.

Berikut adalah contoh modul kecil dengan antarmuka publik, kelas pabrik publik dan dua kelas implementasi paket-pribadi:

src/main/java:
    com.hello.transmogrifier
        public interface Transmogrifier
        public class TransmogrifierFactory
        class MapTransmogrifier implements Transmogrifier
        class ListTransmogrifier implements Transmogrifier

scr/test/java:
    com.hello.transmogrifier
        public class TransmogrifierFactoryTest
        public class MapTransmogrifierTest
        public class ListTransmogrifierTest

Menyembunyikan implementasi antarmuka Transmogrifier bisa menjadi pilihan desain yang valid. Mungkin tanggung jawab kelas pabrik untuk memilih implementasi.

Karena implementasinya bersifat paket-pribadi, Anda perlu menempatkan kelas-kelas tes unit dalam paket yang sama jika Anda ingin mengujinya secara langsung. Jika Anda memiliki kelas uji unit dalam beberapa paket lain, Anda hanya memiliki akses langsung ke antarmuka publik dan kelas pabrik dari pengujian Anda.


1
"Biasanya Anda ingin menulis unit test untuk kelas dan metode paket privat juga". Tidak! Ini praktik yang sangat buruk. Jenis paket pribadi adalah detail implementasi dan tidak boleh diuji secara langsung. Hanya uji API publik.
David Arno

1
@ DavidArno saya tidak setuju. Namun, saya mengganti kata "biasanya" dengan kata "kadang-kadang" untuk menghindari diskusi tertentu.
DATANG DARI

1
Anda mungkin tidak setuju dengan semua yang Anda inginkan, tetapi menguji kerja bagian dalam sepotong kode mengarah pada penggandengan yang erat antara pekerjaan bagian dalam dan tes dan untuk uji rapuh yang mudah pecah selama bahkan refactoring sederhana. Ini praktik yang sangat buruk.
David Arno

Jika saya ingin memastikan semua implementasi Transmogrifier saya berfungsi, apa pun yang dilakukan pabrik, maka saya akan menulis unit test yang menguji setiap implementasi. Perhatikan bahwa implementasinya memiliki API publik bersama meskipun kelasnya adalah paket pribadi. Tes ini tidak boleh rusak kecuali saya mengubah API publik. Sebenarnya, saya mungkin akan menulis tes generik untuk Transmogrifier dan kemudian menjalankannya terhadap setiap implementasi. Meskipun dimungkinkan untuk membuat setiap implementasi menggunakan pabrik, lebih baik tidak memiliki ketergantungan saat menguji Transmogrifiers.
DATANG DARI

Lalu suatu hari, Anda melihat MapTransmogrifierdan ListTransmogrifierdan memutuskan mereka bisa dibuat menjadi satu kelas, sehingga Anda membuat ListMapTransmogrifier, memodifikasi pabrik untuk menggunakan dan menghapus dua kelas. Kode sekarang tidak dikompilasi, jadi Anda harus memodifikasi setiap tes di keduanya MapTransmogrifierTestdan ListTransmogrifierTestuntuk membuatnya dikompilasi. Tes gagal. Apakah itu karena mengubah tes atau pembuatan ListMapTransmogrifier? Keluarlah debugger untuk mencari tahu ... atau ketika tes menggunakan pabrik, Anda melakukan refactor itu dan semua masih mengkompilasi ...
David Arno
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.