Apakah dianggap 'praktik buruk' untuk memeriksa konten file / penyandian dalam pengujian unit?

84

Sedikit konteks: Sebelumnya hari ini saya harus memperbarui beberapa kode SQL yang disediakan oleh rekan saya yang lain, dan karena ini skrip yang cukup besar, disimpan sebagai file terpisah (yang kemudian dibaca dan dieksekusi saat runtime). Saat melakukan ini, saya secara tidak sengaja memperkenalkan kembali dua bug yang kami miliki beberapa bulan lalu, yaitu:

  • Untuk alasan apa pun file ASCII dikodekan dalam UTF-16 (kolega mengirimi saya email file tersebut, yang mungkin menyebabkannya).
  • Script tidak ada SETpernyataan awal (diperlukan karena beberapa hal driver pada produksi, tetapi tidak pada instalasi yang bersih secara lokal).

Setelah men-debug ini sekitar satu jam (lagi) saya memutuskan untuk menulis beberapa tes unit untuk memastikan ini tidak akan terjadi lagi (dan termasuk cara cepat untuk memperbaikinya dalam pesan pernyataan untuk memberikan perbaikan yang mudah bagi pengembang masa depan).

Namun ketika saya mendorong kode ini rekan lain (yang juga pemimpin tim kami) menghampiri saya dan mengatakan bahwa saya tidak boleh membuat hal-hal ini lagi karena:

"Benda-benda ini tidak termasuk dalam unit test"

"Tes unit seharusnya hanya digunakan untuk memeriksa aliran kode Anda"

Saya cukup konflik sekarang karena saya masih berpikir apa yang saya lakukan tidak salah, karena bug ini tidak akan diperkenalkan kembali di masa depan, namun kolega ini bekerja sebagai senior dan pada akhirnya harus memutuskan apa kita menghabiskan waktu kita. Apa yang harus saya lakukan? Apakah saya salah melakukannya dengan cara ini? Apakah itu dianggap praktik yang buruk?

unit-testing Paradoksis
sumber
7
Kemungkinan rangkap dari Haruskah Anda menulis tes otomatis untuk memeriksa apakah data itu benar (isi file konfigurasi, database, dll.)?
Agak
35
" Tes unit seharusnya hanya digunakan untuk memeriksa aliran kode Anda " Saya akan mengatakan itu omong kosong. Secara tradisional mereka harus memasukkan semua tes yang diperlukan untuk memastikan bahwa "unit" yang dipertimbangkan dalam isolasi itu benar. Jika Anda hanya menulis unit test yang bermanfaat untuk "memeriksa alur", apa pun artinya, saya harap Anda juga memiliki suite pengujian ekstensif yang terpisah (ditulis oleh departemen QA?).
gbr
8
Masalahnya, kolega Anda kemungkinan besar hanya di tempat Anda melakukan tes itu. Saya akan fokus pada hal itu, mengesampingkan diskusi denominasi / perang suci. Mungkin saja tes tersebut terlalu lambat untuk suite yang Anda tambahkan, tetapi juga sangat mungkin bahwa kolega Anda hanya terpaku pada gagasannya tentang unit test dan membuat masalah karena masalah yang tidak ada; jadi lebih baik untuk terlebih dahulu mengklarifikasi apa masalah sebenarnya.
gbr
2
Omong-omong, tes-tes itu memang terlihat seperti sesuatu yang ingin Anda jalankan setiap kali Anda memodifikasi file SQL itu. Di sini masalah utama mungkin adalah alat pengujian, yang mungkin tidak mendukung mode operasi "jalankan saja jika dimodifikasi"; itu yang menimbulkan masalah nyata, mungkin bermanfaat untuk memasukkan fungsionalitas "hanya jika dimodifikasi" secara manual dengan beberapa kludge hanya untuk pengujian khusus tersebut.
gbr
5
Alih-alih menguji bahwa file memiliki konten yang benar dan pengkodean mengapa tidak menguji apakah itu berfungsi ?
user253751

Jawaban:

156

Kemungkinan besar tes yang Anda tulis lebih dekat dengan tes integrasi atau regresi daripada tes unit. Sementara baris bisa sangat kabur dan kadang-kadang beralih ke pedantry atas apa yang bukan tes unit, saya akan kembali ke kolega Anda dan bertanya di mana tes yang Anda tulis harus karena mereka menambah nilai memastikan kebenaran kode.

Saya tidak akan terlalu fokus pada apa yang merupakan tes unit atau tidak dan menyadari bahwa bahkan jika tes integrasi, masih ada nilai dalam tes.

RubberChickenLeader
sumber
Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Thomas Owens
36

Secara teknis, ini bukan tes unit, dan lebih merupakan langkah validasi. Pendekatan yang tepat benar-benar tergantung pada apa alur kerja Anda seharusnya. Pimpinan tim Anda benar tentang tujuan tes unit. Perasaan saya adalah bahwa ini adalah kasus menggunakan alat yang salah untuk pekerjaan yang masih perlu dilakukan. Jadi mulailah dengan ini:

Apa masalah yang saya coba selesaikan?

Dengan deskripsi, Anda perlu memvalidasi bahwa skrip basis data apa pun mematuhi beberapa standar.

Alat / proses apa yang tersedia untuk menyelesaikan masalah?

Kualitas kode sumber biasanya diperiksa oleh alat analisis statis . Jika Anda tidak memiliki alat analisis statis untuk memvalidasi SQL Anda, maka Anda dapat membuat alat cepat dan kotor yang melakukan pemeriksaan pada setiap file SQL yang diteruskan ke dalamnya. Tidak ada salahnya untuk memeriksa apakah ada alat analisis statis yang dapat menangani masalah yang Anda bicarakan.

Jika Anda menjadikan itu bagian dari infrastruktur build Anda, seperti memasukkannya ke Jenkins atau semacamnya, itu dapat diterapkan ke semua file SQL di proyek Anda.

Tes unit hanya memecahkan masalah untuk file Anda saat ini.

Bagaimana cara saya mengomunikasikan kebutuhan akan alat ini?

Ini cukup mudah, Anda berbicara dengan pimpinan tim Anda. Ia dapat bekerja dengan pemilik produk dan Anda untuk menentukan risiko / imbalan berinvestasi dalam perkakas. Jika ini kemungkinan merupakan masalah satu kali saja maka tooling mungkin akan berlebihan. Jika alat untuk menangkap masalah terbesar itu mudah, mungkin layak hanya untuk pemeriksaan kewarasan.

Pimpinan tim Anda mungkin memiliki beberapa gagasan yang Anda (atau saya) belum pertimbangkan, yang dapat mengatasi masalah dengan lebih benar.

Berin Loritsch
sumber
21
Ketika membahas biaya vs risiko, penting untuk dicatat bahwa hal itu telah menyebabkan hilangnya waktu karena memperkenalkan kembali bug yang telah diselesaikan sebelumnya. Ini saja merupakan argumen yang kuat untuk mengotomatiskan verifikasi. +1
jpmc26
1
@ jpmc26, saya sepenuhnya setuju. Diskusi harus dimulai dengan fakta bahwa Anda kehilangan waktu berjam-jam untuk mencari tahu apa yang salah, dan unit test Anda adalah upaya pertama Anda untuk mencegah anggota tim lainnya kehilangan jumlah waktu yang sama. Namun, bekerja dengan pemimpin tim yang harus menjawab manajemen dan pemangku kepentingan biasanya sangat dihargai. Sebagai pemimpin tim, saya ingin dapat mempertahankan alat / praktik / kode yang kami kelola. Jika saya melihat unit test yang tidak dapat dilacak ke persyaratan aktual saya juga akan khawatir.
Berin Loritsch
1
@BerinLoritsch Secara teknis, ini bukan tes unit yang saya ingin tahu tentang "teknik" apa yang menjadi dasar pernyataan ini. Sejauh yang saya tahu, tidak ada definisi otoritatif tunggal dari tes unit dan setiap orang memiliki ide sendiri tentang " mereka ".
gbr
2
@ gbr Ada perjanjian informal di antara pengembang bahwa pengujian unit adalah pengujian yang dijalankan secara terpisah dari sistem eksternal. Mereka hanya menguji kode itu sendiri, bukan interaksi dengan file, database, atau layanan eksternal lainnya. Wikipedia mendokumentasikan pemahaman ini: en.wikipedia.org/wiki/Unit_testing#External_work .
jpmc26
1
@BerinLoritsch Mungkin juga kita semua menafsirkan pertanyaan dengan cara yang berbeda, bagaimanapun, itu tidak terlalu rinci dan penulis belum kembali ke siapa pun. Saya tidak terlalu tertarik untuk membahas lebih lanjut tentang klasifikasi tes ini, yang penting adalah jika mereka harus ada (saya cukup yakin mereka harus) dan seberapa sering menjalankannya (di setiap perubahan dalam IDE, di setiap komit lokal, pada setiap dorongan ke repositori pusat, setiap saat ...).
gbr
19

Merupakan praktik yang buruk untuk memanggil tes yang mengakses file "Tes Unit".

Dia: "Hal-hal ini tidak termasuk dalam unit test"

Anda: "Masuk akal, tetapi saya tidak dapat menemukan tempat yang lebih baik untuk meletakkannya. Di mana mereka berada?"

Sayangnya, jenis tes apa yang ada dan bagaimana mereka diorganisasikan sepenuhnya khusus untuk perusahaan. Jadi, Anda harus mencari tahu bagaimana perusahaan Anda menangani tes ini.

Jika Anda belum memiliki cara untuk menjalankan tes otomatis selain dari Tes Unit, pendekatan pragmatis adalah dengan menandai Tes Unit yang sebenarnya bukan Tes Unit dengan awalan, sampai Anda memiliki cukup banyak dari mereka untuk mulai mencari tahu seperti apa tes yang sebenarnya Anda miliki / butuhkan. Setelah itu Anda bisa mulai mengatur.

Peter
sumber
2
Merupakan praktik yang buruk untuk memanggil tes yang mengakses file "Tes Unit". Di sini file yang sedang diakses adalah file sumber . Ini akan diakses sama seperti file sumber apa pun (untuk menguraikannya). Fakta bahwa tes mungkin tidak akan dibuat dalam bahasa yang sama dari "unit" yang diperiksa (SQL) membuatnya tidak ortodoks tetapi tidak akan mempengaruhi klasifikasinya sebagai tes unit. berlanjut ...
gbr
1
... Sebenarnya, penyandian file yang benar adalah "tes" yang dilakukan oleh kompiler setiap kali membaca file sumber. Di sini masalahnya adalah bahwa menjadi file eksternal yang diinterpretasikan pada saat run-time, "tes kompiler" tidak akan berjalan secara otomatis, sehingga sangat tepat untuk menambahkannya secara eksplisit, dan saya pikir itu dapat dianggap sebagai "unit test" yang sepantasnya Cuplikan SQL. Dan tampaknya masuk akal untuk memasukkannya ke dalam paket (potensial) pengujian yang dijalankan pada setiap modifikasi file.
gbr
3
Ngomong-ngomong, yang secara umum direkomendasikan adalah mengakses file eksternal ketika itu bisa diganti dengan tiruan atau sesuatu seperti itu. Dan oleh sebagian besar definisi, unit test dapat mengakses file eksternal atau apa pun, itu hanya sangat dianjurkan, karena dapat memperlambat banyak hal. Toko bebas menentukan bahwa Anda tidak dapat menambahkan tes yang mengakses file ke rangkaian tes yang paling sering dijalankan, tetapi itu tidak membuat tes seperti itu tidak layak untuk penunjukan "unit test", mereka hanya membuat mereka "tidak" dimasukkan ke dalam rangkaian tes yang paling sering dijalankan dari proyek ini ".
gbr
2
@Warbo Ini adalah praktik buruk untuk mengakses file (secara umum), dan alasan (yang paling penting) adalah mereka tidak lambat jika melibatkan "GB membaca tautan NFS yang rapuh", mereka lambat jika, misalnya mengutip Michael Feathers , mereka mengambil 1/10 detik. Itu karena Anda ingin menjalankan tes Anda sesering mungkin, idealnya pada setiap perubahan yang Anda lakukan di IDE, dan ketika Anda memiliki banyak dari mereka (sebagaimana mestinya) bahkan 10 detik detik terakumulasi menjadi berjam-jam. (lanjutan ...)
gbr
1
@Warbo .. Yang mengatakan, yang penting adalah total waktu yang mereka ambil, jadi jika Anda memiliki proyek yang sangat kecil yang Anda yakin akan tetap kecil, Anda bisa jauh lebih lunak tentang kecepatan tes individu. Dan jika Anda benar-benar tidak peduli untuk sering menjalankannya, Anda benar-benar bebas bahkan meminta mereka memanggil karyawan OPMROC untuk mengambil dan mengirimi mereka faks file dari kabinet. Anda juga dapat memilih untuk menjadi lebih longgar sementara Anda masih memiliki beberapa tes dan kembali untuk mempercepatnya ketika mereka mulai mengambil terlalu banyak, tetapi Anda harus memperhitungkan bahwa ini adalah hutang yang Anda kumpulkan.
gbr
14

Michael Feathers mengatakan ini dalam bukunya Bekerja Efektif dengan Kode Legacy:

Dalam industri ini, orang sering bolak-balik tentang apakah tes tertentu adalah tes unit. [...] Saya kembali ke dua kualitas: Apakah tes berjalan cepat? Bisakah ini membantu kami melokalisasi kesalahan dengan cepat?

Apakah tes Anda membantu melokalisasi kesalahan dengan cepat dan berjalan cepat? Jika ya, maka lakukanlah! Jika tidak, maka jangan! Sesederhana itu!

Yang sedang berkata, Anda bekerja di lingkungan dengan orang lain dan harus bergaul dengan mereka. Anda mungkin harus akhirnya melakukannya dengan caranya, bahkan jika Anda secara pribadi tidak setuju dengan itu.

CJ Dennis
sumber
Ini adalah aturan praktis yang baik, tetapi ia akan terhindar dari kebingungan jika ia menulis " apakah akan menambahkan tes tertentu ke rangkaian tes yang paling sering dijalankan ", daripada mengacaukan istilah "unit test".
gbr
1
@ gbr Jika hasil tes akurat, satu-satunya hal lain yang penting adalah seberapa cepat ia berjalan. Jika saya memiliki 100 tes yang masing-masing berjalan di bawah 0,1s, secara total mereka akan berjalan dalam waktu kurang dari 10s. Saya senang sering menjalankannya. Jika saya memiliki 1000 tes, mereka akan membutuhkan waktu hingga 1m40s. Itu terlalu lama, saya tidak akan sering menjalankannya, tapi saya akan menjalankannya setelah saya membuat perubahan dengan kelompok yang lebih kecil dari 100 tes. Saya tidak peduli apakah itu secara teknis tes penerimaan atau sesuatu yang lain. Jika jika membantu saya menemukan kesalahan lebih cepat, saya akan melakukannya terlepas dari semantik. Tes hanya memberikan nilai saat dijalankan.
CJ Dennis
Saya sebagian besar setuju (independensi adalah hal yang sangat penting, misalnya), tetapi meskipun demikian, akan lebih baik jika Michael Feathers tidak memperparah kebingungan tentang apa arti "unit test". Bukannya dia yang harus disalahkan atas kebingungan itu (dan bukunya sangat bagus, di bagian-bagian yang saya selipkan sejauh ini). Lagi pula, saya membuat poin yang agak kecil.
gbr
@ gbr Dia tidak mendefinisikan ulang unit test, dia mengatakan bahwa seharusnya tidak menjadi kriteria Anda untuk dimasukkan. Kriteria Anda haruslah kegunaan, dan itulah yang dia definisikan.
CJ Dennis
Saya membaca kembali bagian itu; Saya tidak yakin, tidak jelas bagi saya apakah itu dimaksudkan sebagai (semacam) definisi atau hanya kriteria. Tetapi sebenarnya " Bisakah itu membantu kita melokalisasi kesalahan dengan cepat " mungkin sangat menyiratkan hal-hal yang dia katakan sebelumnya, tentang isolasi dll. Jadi saya mungkin membuat keributan tentang apa-apa (walaupun jawaban Anda sendiri masih bisa disalahartikan)
gbr
10

Saya pernah menulis tes serupa, kadang-kadang, terhadap file kode sumber, file konfigurasi, dan sebagainya. Saya tidak akan menyebut mereka unit-test karena (a) mereka mengakses sistem file dan mungkin tidak ultra-cepat (b) Saya tidak peduli jika mereka dieksekusi pada setiap check-in (sebagai lawan dari malam pada Server CI).

Anda bisa menyebutnya tes integrasi; tentu saja, mereka lebih dekat ke perspektif itu daripada tes unit.

Istilah saya sendiri untuk mereka adalah tes sumber daya . IMHO, mereka sepenuhnya dibenarkan jika dijalankan setiap malam di server CI: ada biaya minimal dan, ketika digunakan dengan bijaksana, jelas menambah nilai. Satu definisi bijaksana : jika tes memeriksa masalah yang menyebabkan masalah (seperti pengkodean yang Anda sebutkan).

Michael Easter
sumber
4

Tes unit adalah semua tentang pengujian metode atau 'unit' kode. Anda sedang menguji kelompok logika dan kode terkecil dalam perangkat lunak Anda.

Kemudian, ketika Anda bergabung dengan unit lain Anda akan melakukan pengujian integrasi.

Saya harap pimpinan tim Anda mendorong inisiatif Anda dan seharusnya menawarkan saran alternatif. Anda pasti memiliki ide yang tepat.

SQL Anda adalah kode sama seperti bahasa generasi lebih rendah seperti C # atau Java dan harus diuji seperti itu. Dan verifikasi dan validasi adalah milik semua level pengujian. Jadi, pengkodean dan pernyataan SET disertakan, tetapi belum tentu diuji secara eksklusif. Hal-hal umum seperti ujung garis atau penutup Anda biasanya dapat menggunakan kait atau fitur SCM.

Praktik terbaik adalah memiliki tes regresi untuk memastikan bahwa bug masa lalu tidak diperkenalkan kembali. Umumnya, tes dibuat berdampingan dengan resolusi bug apa pun. Jika bug ini tidak dicakup oleh uji regresi pada unit / integrasi atau tingkat sistem dan kemudian diperkenalkan kembali itu adalah masalah tim, masalah proses, bukan individu.

Masalahnya adalah ... kesalahan sintaksis, pernyataan yang hilang atau blok logika di dalam 'unit' biasanya tidak diuji. Anda menguji input dan output unit dalam kombinasi yang berbeda, menguji banyak kemungkinan yang dapat dihasilkan.

Kembali ke pernyataan SET yang hilang - mereka membantu menginformasikan banyak kemungkinan input dan output untuk diuji. Tes apa yang akan Anda tulis yang akan GAGAL jika Anda kehilangan SET yang dipilih?

Ross
sumber
Pengujian "Unit kode" adalah salah satu pendekatan untuk pengujian unit. Dalam pengalaman saya ini mengarah pada tes rapuh dan mengasapi besar (misalnya mengejek berlebihan). Alternatif, dan IMHO lebih baik, pendekatan untuk pengujian unit adalah "unit fungsi". Tidak masalah jika beberapa fungsi (misalnya, "mengatur cookie saat login") memerlukan satu metode atau selusin proses komunikasi, itu masih satu unit.
Warbo
@ Harbo - Saya akan menyebutnya lebih dekat ke (tetapi tidak) pengujian integrasi. Pengujian unit tidak memerlukan apa pun yang berlebihan atau masif. Tes unit harus kecil dan cepat. Sebenarnya pengujian berdasarkan fungsionalitas mengarah pada apa yang Anda uraikan .. Tes rapuh adalah yang 1. lebih besar atau melakukan lebih dari yang seharusnya. 2. sangat berpasangan 3. tidak memiliki tanggung jawab tunggal.
Ross
3

Jika Anda memiliki file yang menjadi bagian dari produk Anda, maka isinya harus benar. Tidak ada alasan mengapa Anda tidak akan memverifikasi ini. Sebagai contoh jika Anda memerlukan enam gambar 1024x 1024 di beberapa folder, maka tentu saja menulis tes unit yang memeriksa Anda memiliki persis itu.

Tetapi Anda mungkin tidak hanya memiliki file, Anda juga memiliki beberapa kode yang membaca file. Anda bisa menulis unit test untuk kode itu. Dalam contoh di atas, apakah fungsi untuk membaca salah satu dari enam gambar mengembalikan gambar 1024 x 1024 dalam memori (atau apa pun yang seharusnya dihasilkan).

Bagaimanapun, ini mungkin bukan tes unit, tetapi ini adalah tes yang berguna. Dan jika Anda menggunakan kerangka kerja unit test yang memungkinkan Anda untuk melakukan tes yang berguna (itu bukan tes unit), mengapa tidak menggunakan kerangka kerja unit test?

gnasher729
sumber
2

Mungkin saya salah paham masalah Anda, tetapi bagi saya ini terdengar seperti masalah yang seharusnya tidak perlu ditangkap dengan segala macam tes khusus tetapi hanya dengan sistem kontrol versi . Setiap perubahan pada basis kode harus ditinjau berdasarkan patch-by-patch sebelum melakukan. Cara sederhana untuk melakukan ini di git adalah menambahkan perubahannya

git add -p

Ini akan untuk setiap perubahan dalam file teks direktori kerja bertanya apakah Anda benar-benar ingin menyimpannya. Itu akan memungkinkan Anda untuk melihat, misalnya, penghapusan " SETpernyataan awal " tersebut.

Dalam kasus pengkodean seluruh file berubah, sesuatu yang berbeda akan terjadi: algoritma akan gagal untuk diff file lama dan baru, dan karena git add -pitu tidak akan menambahkan apa pun sama sekali. Ini kemudian akan terlihat di perintah lain yang akan saya lakukan sebelum komit, yaitu

git status

Di sini Anda akan melihat file disorot dalam warna merah, menunjukkan bahwa ada yang berubah. Menyelidiki mengapa ini tidak berhasil git add -pakan dengan cepat membuat masalah menjadi jelas.

leftaroundabout
sumber
doakan, bagaimana ini membantu para dev di masa depan untuk menghindari masalah yang persis sama? ... satu hal tentang tes otomatis (juga valid tentang pernyataan dan desain-kontrak) adalah bahwa, ya, erm, otomatis .
vaxquis
@vaxquis itu memang mencegah masalah yang sama persis - meskipun agak kebetulan, sebagai efek samping dari alur kerja itu ide yang bagus untuk alasan yang berbeda. Maksud saya adalah, bahwa masalah ini bisa terjadi sama sekali menunjukkan bahwa tim OP tidak menggunakan VCS mereka dengan sangat baik. - Tidak ada yang menentang tes otomatis, tetapi nilainya menguji properti semantik yang mungkin rusak oleh perubahan tidak berbahaya pada logika program. Ini bukan untuk memeriksa setiap cara bodoh yang mungkin di mana kode sumber mungkin berubah.
leftaroundabout
menurut logika Anda, kami tidak membutuhkan sabuk pengaman; kita hanya perlu mengemudi lebih hati-hati dan menyebabkan lebih sedikit kecelakaan ... Anda melewatkan titik utama yang diangkat OP - kesalahan manusia . Tidak ada jumlah VCS yang dapat melindungi Anda dari hal itu . Juga, FWIW: jika tes dapat diotomatisasi, itu harus otomatis. Manusia selalu merupakan mata rantai terlemah dalam proses rekayasa. gitadalah contoh terbaik dari itu - alat yang hebat, namun hampir tidak dapat digunakan untuk manusia biasa .
vaxquis
@vaxquis Tidak, tidak! Sabuk pengaman analog dengan jenis tes yang masuk akal: sabuk pengaman menangkap beragam situasi yang kemungkinan terjadi secara tidak sengaja. Tes pada file-encoding akan dianalogikan dengan robot yang mengikuti Anda berkeliling dan mencegah Anda dari sesak napas dengan memasukkan kacang ke hidung Anda.
leftaroundabout
Menurut OP, file dalam format yang salah telah terjadi dua kali sudah, begitu rupanya mereka yang mungkin terjadi secara kebetulan.
gnasher729
1

Sudut lain untuk dipertimbangkan: karena kedua syarat tersebut adalah persyaratan untuk menjalankan program Anda, bukankah Anda harus menanamkan logika di dekat logika eksekusi? Maksud saya: Anda menguji keberadaan file sebelum membacanya dan / atau memvalidasi kontennya, bukan? jadi bagaimana ini berbeda? Saya pikir karena ini adalah sumber daya kode-eksternal, harus divalidasi saat runtime, sebelum benar-benar digunakan. Hasil: aplikasi yang lebih kuat, tidak perlu menulis tes tambahan.

Gianluigi Zane Zanettini
sumber
1
Bagaimana kegagalan hanya saat runtime menjadikannya aplikasi yang lebih kuat? Tentu, bisa juga tepat untuk memiliki pemeriksaan runtime dekat dengan sumber masalahnya, tetapi jika Anda dapat mendeteksi kesalahan sebelum menyebabkan masalah runtime, itu jauh lebih baik, bukan begitu? Anda yakin terbiasa dengan pengujian otomatis?
gbr
1
"Bagaimana kegagalan hanya saat runtime menjadikannya aplikasi yang lebih kuat?" Lempar pengecualian jika cek gagal. Dalam pengujian Anda, cukup periksa bahwa bagian kode yang diuji mengembalikan hasil yang diharapkan: ini menghilangkan beban untuk memeriksa satu lagi alasan kegagalan.
Dr. Gianluigi Zane Zanettini
1
Strategi Anda hampir tidak ada hubungannya dengan pengujian unit dan pengujian otomatis secara umum, itu adalah hal yang berbeda, dengan kegunaan yang berbeda.
gbr
1
Saya akan menyarankan ini. Bug adalah detail implementasi; Saya membayangkan tanggapan akan sangat berbeda jika pengkodean cerdik berada di bidang pribadi daripada file mandiri! Kedengarannya seperti OP memiliki 2 masalah: file sumber daya mungkin dikodekan dengan buruk, dan produksi berperilaku berbeda terhadap dev. Dengan memeriksa file saat runtime, tepat sebelum digunakan, kami memecahkan masalah kedua: dev dan prod akan melemparkan kesalahan yang sama. Tes unit kemudian dapat fokus pada fungsionalitas aktual daripada detail implementasi; cek "internal" ini akan dilaksanakan seperti metode pribadi.
Warbo
1
@ Dr.GianluigiZaneZanettini Bah ... Saya menyerah ... Seperti yang saya lihat, jawaban terbaik Anda, setelah "klarifikasi" Anda di komentar, adalah di luar topik (bukan jawaban untuk pertanyaan), tetapi dalam kenyataannya, seperti berdiri, itu salah! tidak perlu menulis tes tambahan ??? Saya tidak memiliki reputasi yang cukup untuk menurunkannya, tetapi pertimbangkanlah seolah-olah saya yang melakukannya. Dan saya tidak berpikir ada banyak manfaat dalam melanjutkan percakapan ini.
gbr
1

Tes adalah kode yang sama dengan yang lain dan, jika cukup kompleks, juga mendapat manfaat dari ... pengujian unit. Tampaknya paling sederhana untuk menambahkan pemeriksaan prasyarat seperti itu langsung ke dalam tes.

Sebagian besar tes cukup sederhana untuk tidak memerlukan ini, tetapi jika beberapa cukup kompleks, saya tidak melihat ada yang salah secara fundamental dengan pemeriksaan pra-kondisi ini. Tentu saja, tes juga harus gagal tanpa mereka, tetapi tes unit yang baik juga memberitahu unit mana yang gagal.

Sebuah skrip yang digunakan sebagai bagian dari pengujian dan harus memiliki konten dan penyandian tertentu mungkin merupakan unit. Mungkin memiliki lebih banyak kode dan logika daripada tes lainnya. Pengujian dengan skrip semacam itu bukanlah desain terbaik yang pernah ada dan, jika mungkin, harus dire-refored menjadi sesuatu yang lebih langsung (kecuali ini adalah tes integrasi).

h22
sumber
1
penulis tidak mengatakan di mana pun bahwa skrip SQL adalah bagian dari beberapa tes, Anda tampaknya salah membaca pertanyaan
gbr
Ada yang sulit dimengerti, saya menganggap skrip SQL adalah bagian dari tes.
h22
komentar Anda "Ada yang sulit dimengerti" ...
gbr
Sulit dimengerti. Menurunkan pertanyaan.
h22
1

Pertama - salah satu tujuan tes adalah untuk mencegah masalah berulang dalam kode Anda - jadi Anda harus tetap menulis tes seperti ini.

Kedua - penamaan itu sulit. Ya, ini jelas bukan "unit test", tetapi itu bisa menjadi bagian yang diinginkan dan diperlukan dari proses build, karena mereka melindungi Anda dari kesalahan yang jelas, dan karena mereka memberi Anda umpan balik tentang kesalahan lebih cepat (terutama mengingat Anda tidak melihat konsekuensi pada kotak dev).

Jadi, pertanyaannya adalah (seharusnya dalam konteks Anda) lebih banyak tentang kapan dan bagaimana tes ini dijalankan daripada apa itu.

Saya telah menggunakan tes semacam ini secara luas di masa lalu - mereka telah menyelamatkan kita dari rasa sakit yang cukup.

Murph
sumber
Dan jika seseorang mau menjelaskan downvote saya akan menghargainya
Murph
1

Tes unit adalah tentang mengeksekusi unit kode secara terpisah untuk mengonfirmasi bahwa ia menghasilkan hasil yang benar untuk input yang benar. Isolasi harus membuat unit yang diuji dan tes itu sendiri berulang yaitu tidak boleh bergantung pada atau menimbulkan efek samping.

SQL bukanlah sesuatu yang dapat diuji secara terpisah, jadi setiap pengujian SQL bukanlah uji unit, dan, kecuali untuk pernyataan SELECT, hampir pasti memiliki efek samping. Kita bisa menyebutnya tes integrasi daripada tes unit.

Itu selalu bijaksana untuk memastikan bahwa setiap cacat yang dapat diperkenalkan dapat dideteksi sedini mungkin dalam siklus pengembangan, dan bermanfaat untuk melakukannya dengan cara yang memudahkan untuk mengidentifikasi sumber cacat sehingga dapat dengan cepat dikoreksi.

Tes yang dimaksud mungkin lebih tepat dipindahkan keluar dari badan "unit test" dan ditempatkan di tempat lain, tetapi tidak boleh dihapus sama sekali jika mereka melakukan sesuatu yang berguna seperti menjaga terhadap kemungkinan pengenalan cacat yang bisa memakan waktu berjam-jam untuk dilacak. turun.

Zenilogix
sumber