Apakah pengkodean dan pengujian unit melanggar prinsip KERING

8

Prinsip kering menyatakan:

"Setiap pengetahuan harus memiliki representasi tunggal, tidak ambigu, otoritatif dalam suatu sistem."

Namun ketika menulis tes untuk kode Anda menggambarkan perilaku yang diharapkan untuk sistem dua kali (sekali dalam kode dan sekali dalam tes). Saya tahu kedua deskripsi berasal dari perspektif yang berbeda tetapi berbagi banyak ide mendasar.

Ada pemikiran tentang ini?

Secara umum saya pikir tes unit dan prinsip KERING adalah ide yang bagus dan saya mencoba menerapkannya sebanyak mungkin. Pertanyaan ini lebih pada tingkat filosofis, tetapi saya bertanya-tanya apakah ada yang juga memikirkan hal ini.

testing dry

— refro
sumber

4

1. Kode bukanlah perilaku yang diharapkan, itu adalah perilaku aktual. 2. Tes bukan milik sistem, jadi KERING masih berdiri.

— mouviciel

12

Anda beroperasi pada premis yang salah.

Kode ini bukan merupakan deskripsi perilaku yang diharapkan, hanya persyaratan dan kasus uji saja. Dan bahkan kemudian, persyaratan dan tes menentukan dua sisi perilaku. Persyaratan menentukan karakteristik dan fungsionalitas sistem perangkat lunak secara keseluruhan dan pengujian menentukan apa hasil yang diharapkan dan cocok dengan persyaratan. Kode tersebut adalah interpretasi pengembang terhadap persyaratan dan arsitektur sistem.

— Thomas Owens
sumber

Saya berpikir dengan cara yang sama, namun satu catatan perbedaan: tes unit juga didasarkan pada interpretasi pengembang tentang persyaratan dan arsitektur, sehingga tidak ada kesalahpahaman pada level ini antara tes unit dan kode (setidaknya dengan TDD greenfield) - kode lawas adalah masalah yang berbeda). Ini adalah tes penerimaan yang / harus didasarkan pada definisi persyaratan pelanggan.

— Péter Török

@ PéterTörök Untuk pengujian unit, itu tergantung pada siapa yang menulis tes. Itu benar sekali jika pengembang yang sama menulis tes dan kodenya. Jika satu pengembang menulis tes dan satu menulis kode, maka Anda memiliki dua interpretasi pengembang dan dapat melihat masalah lebih cepat. Adapun tingkat pengujian yang berbeda, saya menggunakan istilah "tes" untuk merujuk pada unit, integrasi, sistem, dan tes penerimaan, masing-masing ditulis oleh orang atau kelompok yang sesuai untuk tujuan yang diberikan. Jika orang yang salah menulis tes (pengembang menulis tes penerimaan, misalnya), tes itu tidak berguna.

— Thomas Owens

6

Tidak, itu tidak melanggar prinsip KERING karena unit test tidak mereproduksi fungsionalitas, mereka hanya memastikan fungsionalitas (re: tanggung jawab) beroperasi dengan benar. Dalam hal unit test, metode yang Anda uji masih dipertahankan authoritative representation. Kode tes Anda mungkin terlihat sangat mirip dengan kode yang mengimplementasikan metode dalam versi produksi, tetapi memiliki tujuan yang jelas (untuk menegaskan tes).

— Joel Etherton
sumber

3

Agak. Jika mereka terlalu mirip, maka ya, itu hal yang buruk. Tes Anda tidak boleh dikodekan dengan cara yang sama dengan kode yang diuji. Jadi, Anda harus mendefinisikan (1) harapan dan (2) implementasi.

Saya suka berpikir bahwa ini mirip dengan akuntansi entri ganda . Sistem akuntansi selalu membuat setidaknya 2 entri (debit dan kredit). Ini adalah ukuran pengecekan kesalahan. Pada akhirnya, debet dan kredit harus seimbang, atau ada kesalahan. Anda tidak dapat memiliki sistem pendeteksian kesalahan tanpa redundansi.

Sebagai contoh, pertimbangkan CRC . Byte CRC Anda adalah bentuk redundansi. Cukup untuk mendeteksi kesalahan kecil pada sinyal. Demikian pula, CD audio memiliki banyak informasi yang berlebihan sehingga mereka masih dapat diputar dengan sempurna jika tergores. Apakah itu melanggar prinsip KERING? Mungkin, tapi begitulah cara Anda mendapatkan keandalan.

Ada cara lain untuk melihatnya juga:

Tes Anda adalah jawaban resmi. Kode yang diuji hanya dihasilkan secara otomatis oleh Anda, kode monyet. Jika kita dapat melakukan pembuatan kode secara otomatis berdasarkan pada tes unit (seperti kita membuat lapisan akses data secara otomatis berdasarkan skema basis data) maka kita tidak akan melanggar prinsip KERING (atau setidaknya bukan prinsip OAOO).

— Scott Whitlock
sumber

3

Namun ketika menulis tes untuk kode Anda menggambarkan perilaku yang diharapkan untuk sistem dua kali (sekali dalam kode dan sekali dalam tes).

Tidak terlalu. Kode bukanlah deskripsi perilaku yang diharapkan, tetapi implementasinya . Yang bisa mengandung kesalahan, itu sebabnya kami membutuhkan tes.

Menerapkan bahkan algoritma atau abstraksi yang cukup sederhana jauh lebih sulit daripada menggambarkannya. Setiap programmer yang baik dapat menjelaskan dalam beberapa kalimat bagaimana pencarian biner bekerja - masih, Jon Bentley melaporkan bahwa dalam eksperimennya, lebih dari 70% programmer berpengalaman yang berpartisipasi dalam kursusnya gagal mengimplementasikannya dengan benar.

Inilah sebabnya kami membutuhkan unit test. Tidak ada yang suka bekerja dua kali lebih banyak untuk mencapai hasil yang sama, tetapi semua pengembang yang merumuskan dan menginjili praktik ini menyadari dari pengalaman susah payah mereka sendiri bahwa mereka membutuhkannya. Mereka adalah orang-orang pintar yang ingin mengembangkan perangkat lunak secepat mungkin - yang membutuhkan penghapusan semua tugas yang digandakan dan tidak berguna dari proses pengembangan. Tes unit bukan pekerjaan rangkap.

— Péter Török
sumber