Seharusnya tes unit hanya mencakup perangkat lunak 'fungsional'

Kami menggunakan StructureMap dalam proyek pengembangan perangkat lunak baru. Salah satu anggota tim telah menerapkan uji unit yang pada dasarnya menguji konfigurasi kontainer StructureMap . Ini melakukan ini dengan melakukan hal berikut;

• Menghitung jumlah instance rakitan yang dikonfigurasikan untuk kelas di namespace aplikasi kami.
• Menentukan instance yang diharapkan di tingkat kelas
• Menyatakan bahwa instance yang diharapkan cocok dengan total instance yang ditemukan.
• Menyatakan bahwa instance yang diharapkan cocok dengan yang didefinisikan dalam tes

Contohnya adalah;

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

Kami juga memiliki 'unit test' untuk kelas berikut;

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

Dalam tes ini, kami mengejek IEnvironmentRepository, jadi tidak akan menyuntikkannya dari wadah seperti yang akan terjadi pada sistem live.

Seorang kolega mengabaikan tes unit pada konfigurasi structuremap dengan komentar di sepanjang baris "Tes unit hanya menguji konfigurasi sendiri". Ini jelas tujuan dari tes dan menurut saya sangat valid. Saya bertanya kepada orang yang mengabaikan tes untuk menghapus konfigurasi structuremap untuk IEnvironmentRepository(dengan tes masih diabaikan) dan menjalankan unit test unit lengkap, mereka semua lulus. Kami kemudian menjalankan aplikasi dan gagal karena konfigurasi kontainer sekarang tidak valid. Menurut pendapat saya, ini membuktikan nilai tes, kolega saya masih tidak setuju. Dia hanya menyatakan bahwa kita tidak boleh menguji konfigurasi, tetapi saya anggap ini baik dalam pengiriman unit test.

Jadi sejumlah pertanyaan;

• Apakah ini tes unit yang valid - Kami sedang menguji konfigurasi kontainer kami, bukan berarti structuremap berfungsi (tapi saya bisa melihat tumpang tindih)
• Jika tidak, bagaimana Anda bisa memvalidasi konfigurasi tanpa mengujinya. Bagaimana Anda bisa menghentikan seseorang secara tidak sengaja menghapus baris kode yang diperlukan dan memeriksanya?
• Haruskah MyClassunit test menyelesaikan instance dari IEnvironmentRepositorywadah dan meneruskannya?

Ini adalah tes otomatis yang sangat valid untuk dimiliki. Saya menyebutnya "tes arsitektur" karena mereka memverifikasi tingkat kesehatan komponen kerangka basis kode Anda.

Apakah wadah IoC dapat menyelesaikan dan menyusun semua pohon objek dalam aplikasi? Bisakah Mapper otomatis memetakan antara semua objek yang terdaftar tanpa gagal? Apakah layer pusat dalam Arsitektur Bawang tidak mereferensikan sesuatu yang eksternal?

Tes-tes ini dapat menghemat banyak waktu Anda ketika bug konfigurasi masuk, dengan menunjuk pada penyebab yang tepat. Kerangka kerja yang baik akan memberi Anda pesan kesalahan yang sangat tepat tentang apa yang salah dan Anda mendapatkannya segera setelah Anda menjalankan tes (idealnya, terus menerus) alih-alih terkubur jauh di dalam jejak tumpukan runtime jika Anda beruntung.

Apakah mereka adalah unit test ... mungkin tidak, tetapi mereka masih beroperasi dalam memori untuk sebagian besar dan berjalan cukup cepat. Kemudian lagi, saya tidak tahu, tidak seperti ada definisi unit test yang diterima secara universal.

Masalah dengan tes seperti ini yang menguji internal program, bukan persyaratan itu. Apakah tes itu dapat gagal bahkan jika program bekerja sesuai kebutuhan.

Dalam kasus Anda, setiap kali Anda mengubah pengaturan wadah, mungkin Anda memiliki ketergantungan baru yang perlu disuntikkan, Anda memecahkan tes Anda.

Selain itu, jika Anda menambahkan persyaratan ketergantungan ekstra, tetapi lupa untuk menambahkannya ke wadah dan ubah tes wadah. semuanya akan berlalu, tetapi program Anda akan macet.

Tes otomatis yang lebih baik akan memulai program dan melihat apakah itu crash.

Anda harus mengetahui jenis-jenis kesalahan ini saat integrasi atau pengujian UI meskipun mereka gagal dalam pengujian unit.

Karena itu, meningkatnya kompleksitas pengaturan wadah adalah rasa sakit di pantat. Mungkin beberapa tes 'buruk' tidak sia-sia.

Tes unit tes kode. Apa pun di luar ini adalah pengujian otomatis "lainnya" - sebut saja apa yang Anda inginkan. Anda tampaknya menguji konfigurasi di sini. Jika konfigurasi dapat berubah tergantung pada lingkungan, itu tidak termasuk dalam unit test. Pertimbangkan untuk menambahkan atribut tes untuk menunjukkan bahwa tes ini memiliki tipe yang berbeda dengan tes lainnya.

Tanggung jawab wadah injeksi ketergantungan adalah merekatkan berbagai modul dalam satu aplikasi yang berfungsi .

Jika Anda menulis tes otomatis untuk aplikasi Anda - Anda harus memiliki beberapa tes "integrasi (atau penerimaan) yang menjalankan tes" dari ujung ke ujung ", yang akan menguji seluruh pipa aplikasi Anda, bahwa semua modul yang terlibat dalam kasus uji tertentu direkatkan bersama dengan benar .

Jadi tes integrasi tersebut akan gagal jika wadah injeksi ketergantungan tidak dikonfigurasi dengan benar. Yang membuat pengujian unit untuk wadah itu sendiri tidak berguna, karena tes integrasi harus menunjukkan kemungkinan kesalahan dalam konfigurasi wadah.

Anda tidak perlu membahas semua kasus uji yang mungkin dalam tes integrasi, cukup satu kasus uji per fitur yang mencakup sepenuhnya dari UI ke database.

Jika kasus uji integrasi tidak mencakup contoh ketergantungan tertentu - Anda cukup menambahkan yang seperti itu.

Dengan tes integrasi, Anda dapat dengan bebas mengganti wadah tanpa menulis ulang unit test untuk konfigurasinya.

IMO, jawabannya adalah:

1. Apakah ini tes unit yang valid - Kami sedang menguji konfigurasi kontainer kami, bukan berarti structuremap berfungsi (tapi saya bisa melihat tumpang tindih)

   • Ini unit test yang valid untuk structuremap , bukan untuk proyek Anda, karena tes unitary menguji beberapa kode tertentu, mengejek semua dependensi jika perlu untuk menguji logika yang diterapkan. Logika konfigurasi diterapkan di dalam structuremap, oleh karena itu pustaka ini harus diuji dengan baik dan harus berisi unit test seperti yang Anda sebutkan, dan lebih banyak lagi: itu harus berisi ratusan tes seperti ini, secara dinamis mengejek beberapa konfigurasi saat runtime dan menguji untuk melihat apakah wadah berperilaku sebagaimana mestinya.

2. Jika tidak, bagaimana Anda bisa memvalidasi konfigurasi tanpa mengujinya. Bagaimana Anda bisa menghentikan seseorang secara tidak sengaja menghapus baris kode yang diperlukan dan memeriksanya?

   • Anda dapat menguji konfigurasi secara manual di lingkungan yang diperlukan, dan Anda juga dapat membuat otomatisasi untuk ini (tes otomatis), yang menguji konfigurasi spesifik yang Anda butuhkan (tidak perlu mengejek hal-hal saat runtime).

3. Haruskah uji unit MyClass menyelesaikan instance IEnvironmentRepository dari wadah dan meneruskannya?

   • Tidak, ini adalah unit test yang sempurna, karena Anda mengejek ketergantungan dan menguji logika MyClass secara terpisah.

UnitTest memverifikasi perilaku unit yang diinginkan dalam pemisahan .

Ini berarti setiap jenis konfigurasi adalah tidak dalam lingkup UnitTests .

Meskipun demikian Anda harus memiliki tes otomatis untuk konfigurasi Anda, tetapi ini bukan UnitTests ...