Apakah praktik yang buruk untuk memisahkan tes unit untuk kelas? [Tutup]


8

Kelas saya biasanya memiliki sekitar 5-20 metode maksimum, yang menyiratkan bahwa kelas yang memiliki unit test memiliki tentang metode ganda (menghitung dataProviders, setUp, ...)

Saya berpikir untuk memisahkan tes dalam 2-3 kelas, karena meskipun saya mencoba untuk mengikuti prinsip tanggung jawab tunggal, saya lebih suka 2 kelas tes dengan masing-masing 10 metode, daripada satu dengan 20.

Apakah ini praktik yang buruk ?? Apakah bagus untuk memiliki semua tes untuk satu kelas hanya dalam satu, meskipun kelas tes tumbuh secara vertikal?


4
memiliki terlalu banyak unit test tampak seperti gejala kelas yang melanggar prinsip tanggung jawab tunggal . Alih-alih mengatasi gejala, atasi penyebab utama dalam desain kelas
agas


Satu keuntungan memiliki semua pengujian Anda dalam satu file adalah membantu beberapa IDE secara otomatis mengetahui tes mana yang dikaitkan dengan kelas mana yang didasarkan pada nama mereka. Tetapi pada titik tertentu, ini tidak banyak pertimbangan dibandingkan dengan menjaga tes Anda terorganisir dengan baik.
Kevin

Terima kasih agas atas jawaban Anda, saya telah memperbarui pertanyaan untuk memfokuskan hanya tentang memisahkan tes.
luisandani

Jawaban:


18

Untuk menjawab pertanyaan spesifik, sangat mungkin bahwa pengelompokan tes menjadi beberapa kelas adalah keputusan yang baik, acara ketika kelas yang diuji dirancang dengan baik.

Kode uji unit seperti kode lainnya: harus mengikuti prinsip-prinsip desain yang baik ( KERING , GRASP , CIUMAN , SOLID , YAGNI , dll). Karena logika yang membentuk kode pengujian seringkali lebih sederhana daripada logika domain, banyak poin spesifik tidak akan muncul sebanyak ini, tetapi ingatlah saat menulis semua pengujian Anda.

Ada beberapa prinsip yang terlintas dalam pikiran yang dapat dengan mudah diterapkan ketika memikirkan pertanyaan Anda:

Keterbacaan

Idealnya, begitu ujian ditulis, Anda tidak perlu melihatnya lagi; tetapi hal yang sama dapat dikatakan untuk kode apa pun. Kenyataannya adalah bahwa persyaratan berubah, jadi kami mendapati diri kami membaca kode lebih dari menulisnya. Bahkan ketika melakukan yang terbaik, Anda mungkin menemukan bahwa tes yang Anda tulis tidak cukup memverifikasi apa yang Anda pikirkan, pada titik mana Anda harus kembali dan mencari tahu apa yang salah. Menemukan bahwa metode pengujian dalam kelas metode 40-50 akan menjadi sulit, belum lagi kerumitan penamaan metode tersebut sehingga mereka dapat dibedakan dengan mudah.

Kohesi Tinggi

Setiap kelas tes (seperti kelas lainnya) harus memiliki fokus yang jelas. Jika Anda memiliki banyak kasus uji berbeda untuk metode tertentu dari kelas yang diuji, seperti ketika tes yang diberikan memverifikasi satu hal, letakkan metode uji tersebut di kelas yang terpisah dan beri nama untuk mencerminkan fokusnya.


3
Sebenarnya, Anda mungkin ingin melihat tes bahkan jika tidak ada persyaratan yang berubah - hanya untuk memahami bagaimana kelas yang diuji dimaksudkan untuk digunakan, misalnya.
Paŭlo Ebermann

7

Hampir tidak penting bagaimana tes unit Anda diorganisasikan dibandingkan dengan menempatkannya di tempat pertama.

Modul atau kelas kode bisnis adalah sesuatu yang harus Anda pahami sebagai sebuah unit dan dikembangkan lebih lanjut. Itulah alasan utama kami berusaha untuk membuatnya koheren, mudah dipahami secara keseluruhan, dll. Ruang uji hanya kumpulan kasus yang harus dilewati semua; mereka tidak memiliki hubungan khusus satu sama lain . Idealnya, Anda tidak perlu menghadapinya lagi; jika Anda melakukannya biasanya menambahkan lebih banyak tes lagi yang tidak memiliki hubungan khusus dengan tes lain, dan mereka tidak pernah dipanggil oleh kode klien kecuali kerangka unit test.

Oleh karena itu, pertanyaan tentang bagaimana mengatur kelas yang berisi tes unit jauh lebih penting daripada bagaimana mengatur kelas yang membentuk aplikasi Anda sendiri. Anda tidak seharusnya berurusan dengan mereka sebagai struktur makro yang dirancang dengan baik.


Meskipun saya pikir Anda secara umum benar, ada beberapa hal yang lebih buruk daripada tes kereta, rapuh, tidak jelas, dan sulit untuk diikuti. Kode tes spageti tidak bagus.
Paul Draper

3

Masukkan tes dalam satu file. Biasanya untuk setiap file kelas saya akan memiliki file tes. Biasanya menambahkan "Tes" ke nama file.

Misalnya, jika ada kelas yang disebut "Foo" akan ada file "FooTests" yang sesuai. Dengan cara ini untuk setiap file kode ada hubungan 1 hingga 1 antara file kode dan file tes.

Ini memberikan konsistensi dan membuatnya lebih mudah bagi pengembang untuk menemukan tes dan tetap memperbaruinya. Tes biasanya dikecualikan dari analisis kode / metrik jadi jika file tersebut besar, itu tidak merusak metrik kesehatan kode keseluruhan, jadi saya tidak menganggap itu bentuk buruk untuk memiliki file tes dengan banyak kode unit test.


3

Jika kami mengatakan bahwa definisi praktik buruk dalam pengembangan perangkat lunak adalah apa pun yang tidak membantu Anda mengatasi dan merangkum perubahan, maka saya akan mengatakan tidak menjaga kelas dan tes Anda dalam hubungan satu ke satu adalah praktik yang buruk . Ini adalah bau kode yang mungkin timbul karena hal-hal yang disebutkan di bawah ini.

Jelas ada pengecualian seperti dengan apa pun tetapi hanya perlu diingat saat Anda menulis tes Anda.

Kelas saya biasanya memiliki sekitar 5-20 metode maksimum.

Jika salah satu kelas Anda memiliki 20 (atau sedikit kurang) metode semacam itu menunjukkan kepada saya bahwa kelas itu melakukan terlalu banyak di tempat pertama. Di sinilah pengujian unit harus mengisyaratkan Anda bahwa Anda mungkin perlu memecah kelas Anda sedikit lebih dan mendistribusikan tanggung jawab sebelum melanjutkan pengujian.

Sedangkan untuk menjaga mereka di kelas yang sama atau tidak, saya akan menyarankan mencoba untuk menjaga mereka di satu kelas jika memungkinkan karena itu lebih baik dimengerti - koneksi satu ke satu mudah dipahami setelah banyak waktu berlalu. Hanya dari pengalaman.

Jika Anda melihat bahwa tes unit sangat besar bahkan ketika Anda memiliki 5 metode atau kurang maka itu memberitahu saya bahwa kode pengaturan Anda melakukan terlalu banyak atau objek Anda sangat besar .

Jika Anda belum mencoba, lihat pola pembangun untuk membangun objek Anda - ini dapat mengurangi kode secara drastis tentang cara Anda membangun objek Anda sebelum mengujinya. Oleh karena itu membuat kelas tes unit lebih pendek dan lebih sedikit kebutuhan Anda untuk memotongnya menjadi lebih banyak kelas.


Ini adalah saran yang bagus, tetapi bukan jawaban untuk pertanyaan itu. (Masih diunggulkan)
Jon Raynor

@ JonRaynor terima kasih! Saya baru saja memperbarui jawaban saya dengan suatu kesimpulan, khususnya menjawab pertanyaan itu.
AvetisG

Bisakah Anda jelaskan tentang downvote?
AvetisG

1
@AvetisG: Orang tidak perlu menguraikan downvotes mereka dan tidak adil untuk meminta mereka melakukannya. Tetapi saya akan mencoba membantu Anda ... Hanya paragraf pertama di sini yang mencoba menjawab pertanyaan. Sisanya adalah pendapat, yang tidak akan dibagikan sebagian orang. Saya, secara pribadi, setuju dengan pendapat Anda tetapi saya tidak setuju dengan satu paragraf yang relevan dengan pertanyaan tersebut, dan saya tidak melihat hubungan yang Anda buat. Jawaban Mike benar: "Setiap kelas tes (seperti kelas lainnya) harus memiliki fokus yang jelas." Itu mungkin atau mungkin tidak menjadi fokus yang sama dengan kelas Anda yang sedang diuji.
pdr

@ pdr itu masuk akal. Terima kasih telah mengembangkannya.
AvetisG
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.