Selama ulasan berikutnya tentang Permintaan Tarik yang tebal, saya menemukan Tes Unit dengan penamaan kasus tes yang salah. Diskusi tentang kata-kata dalam kasus uji ternyata mirip dengan percakapan antara Yanychar dan Legkostupov dalam film "72 meter" ("jika itu sangat dimengerti di sekolah ..."). Percakapan terdengar gagasan bahwa dalam sumber daya berbahasa Rusia sulit untuk menemukan panduan penjelasan tepatnya dengan kata-kata tekstual. Saya memutuskan untuk mencari sendiri dalam bahasa Rusia (biasanya saya hanya menggunakan sumber berbahasa Inggris). Pada habr ditemukan beberapa manual tentang unit test, tetapi semuanya memotong detail formulasi dalam test case. Di bawah potongan, upaya saya untuk mengisi celah ini.
Disclamer
Ada kemungkinan saya terlihat buruk / membaca terlalu diagonal. Berikut adalah contoh bagaimana topik artikel ini dibahas dalam artikel-artikel yang menarik perhatian saya.
TDD untuk pemula
Atas permintaan rekan-rekan, yang merasa tidak nyaman membaca buku pedoman bahasa Inggris, saya memutuskan untuk menerjemahkan dan menyusun buku pedoman berbahasa Inggris.
Dari penerjemah
Saya mengambil dua bahan ini sebagai dasar artikel:
Saya juga harus mencatat bahwa dalam beberapa contoh uji saya harus melakukan terjemahan parsial ke dalam bahasa Rusia. Kata-kata dalam blok "uraikan" sengaja tetap dalam bahasa Inggris, sebagai dengan probabilitas tinggi mereka akan berisi nama fungsi, modul JS, atau entitas lain dalam kode, tetapi di blok "it" teks sudah diterjemahkan untuk dibaca.
Preferensi pribadi saya adalah bahwa semua yang ada dalam kode harus dalam bahasa Inggris.
Tes penamaan
Nama tes harus menggambarkan tujuannya sesingkat dan sejelas mungkin. Nama dan deskripsi tes adalah hal pertama yang harus mengindikasikan penyebab kegagalan fungsi. Hasil tes di konsol harus dibaca dengan benar dalam hal tata bahasa. Pengembang pihak ketiga seharusnya tidak memecahkan teka-teki di kepala mereka, mencoba menebak apa yang dipikirkan oleh penulis tes. Tes adalah bagian dari dokumentasi untuk program dan harus ditulis dengan benar.
Contoh BAD :
describe('discoveryService => initDiscoveries', () => { it(' discoveries ( , ..)', () => {
Dari contoh-contoh di atas, sulit untuk memahami tindakan spesifik apa yang dilakukan dan apa hasil konkret dari tindakan tersebut.
Contoh BAIK :
describe('discoveryService => initDiscoveries', () => { it(' discoveries', () => {
Catatan perev. # 1: perhatikan bahwa blok teks di dalamnya dimulai dengan huruf besar, sebagai adalah kelanjutan dari kalimat yang dimulai dalam descibe .
Catatan perev. # 2: dalam contoh di atas, "discoveryService => initDiscoveries" tetap lebih baik dibagi menjadi dua blok descibe (satu bersarang di yang lain).
Catatan perev. # 3: perhatikan bahwa dalam contoh tentang penemuan di atas tidak ada bagian kedua dari deskripsi kasus uji; ini menyiratkan teks bentuk "atas permintaannya," yang tidak terlalu baik dari sudut pandang manifestasi; dalam kasus sederhana, salin-tempel "ketika disebut" tidak terlalu menguntungkan, IMHO.
Dalam blok uraian, deskripsi pekerjaan dasar (Satuan Kerja, UoW) biasanya ditempatkan. Kata-kata dalam blok itu harus dilanjutkan dengan pola " unit kerja - skenario / konteks - perilaku yang diharapkan " yang dimulai dengan menggambarkan:
[ ] [ / ] ( | ) [ ]
atau sebagai kode:
describe('[unit of work]', () => { it(' [ ] / [/]', () => { }); });
Jika beberapa kelompok uji mengikuti skrip yang sama atau masuk ke konteks yang sama, Anda dapat menggunakan uraian blok bersarang.
describe('[unit of work]', () => { describe('// [scenario/context]', () => { it('/ [expected behaviour]', () => { }); }); }); describe(' Gallery', () => { describe(' ', () => { it(' ', () => { }); it(' ', () => { }); });
ONE TEST - ONE MASALAH
Setiap tes harus fokus pada satu skenario spesifik dalam aplikasi. Tes, yang bertanggung jawab untuk satu aspek tertentu, dapat mengidentifikasi penyebab spesifik dari kegagalan fungsi. Semakin spesifik tes, semakin kecil kemungkinannya bahwa ada beberapa alasan untuk perilaku yang salah. Cobalah untuk menempatkan hanya satu blok harapan dalam satu blok itu .
Contoh BAD :
describe('isUndefined function', ()=> { it(' true or false undefined', () => { expect(isUndefined(undefined)).toEqual(true); expect(isUndefined(true)).toEqual(false); }); });
Blok itu berisi dua blok harapan . Ini berarti bahwa pengembang, melihat hasil negatif dari tes ini, tidak akan dapat menentukan dengan tepat apa yang salah dalam kode-nya dan bagaimana cara memperbaikinya.
Contoh BAIK :
describe('isUndefined function', ()=> { it(' true, undefined', () => { expect(isUndefined(undefined)).toEqual(true); }); it(' false ', () => { expect(isUndefined(true)).toEqual(false); }); });
Setiap tes dalam contoh di atas mengevaluasi satu masalah khusus. Selain itu, deskripsi tes dengan jelas menjelaskan tentang kasus apa yang akan dilewati. Dalam kedua kasus di konsol, pengembang akan membaca daftar hasil apa yang diharapkan berdasarkan tindakan / kondisi apa dari fungsionalitas pengguna yang diuji.
Menguji perilaku
Lihatlah gambarnya, jangan lihat guratannya. Uji skrip / perilaku khusus, bukan detail implementasi. Maka mengubah detail implementasi tidak akan memengaruhi hasil tes. Hasil tes negatif harus menunjukkan apakah program berperilaku dengan benar dari sudut pandang pengguna. Tes tidak boleh mengontrol / membatasi detail implementasi.
Contoh BAD :
it(' discovery ', () => { discoveriesCache.addDiscovery('57463', 'John'); expect(discoveriesCache._discoveries[0].id).toBe('57463'); expect(discoveriesCache._discoveries[0].name).toBe('John'); });
Apa yang buruk di sini? Pertama, dua blok harapan , tetapi ini bukan hal utama. Kedua, bukan perilaku yang diuji, tetapi detail penerapannya. Detail implementasi akan berubah (bidang pribadi diubah namanya) - tes akan menjadi tidak valid dan perlu ditulis ulang.
Contoh BAIK :
it(' discovery ', () => { discoveriesCache.addDiscovery('57463', 'John'); expect(discoveriesCache.isDiscoveryExist('57463', 'John')).toBe(true); });
Contoh ini menguji API publik yang harus setestabil mungkin.
KESIMPULAN DARI TRANSLATOR
"Onegin adalah seorang pengedarnya ..." Saya mendapat kesan bahwa sebagian besar pengembang sedikit memperhatikan keakuratan dan keterbacaan nama uji. Seringkali saya mengamati diskusi yang agak panjang seperti "Apa yang dilakukan kode ini" atau "Mengapa kode ini." Ini berlaku untuk kedua kode utama dalam JS (tidak jelas, nama fuzzy modul, layanan, fungsi dan variabel), dan tes (kasus buram, pengujian detail implementasi, deskripsi fuzzy). Semua ini mengarah pada fakta bahwa kode tidak sesuai dengan yang diharapkan.
Dalam salah satu wawancara, David Heinemeier Hansson (pencipta kerangka Rails) mengatakan sesuatu seperti berikut:
"Tes unit hanya menunjukkan bahwa program Anda melakukan hal yang diharapkan%: o."
Maksudnya perilaku harus diuji, bukan unit kode. Dan bahasa tekstual harus memiliki pola perilaku. Yaitu "Entitas A harus berperilaku sedemikian dan dalam kondisi ini dan itu." Rantai bentuk menggambarkan [- jelaskan ] - itu - diharapkan akan berubah menjadi formulasi lipat.
Terima kasih atas perhatian anda!