Bagaimana tes integrasi mengkritik desain?


38

Saya membaca di posting blog JB Rainsberger tentang tes terintegrasi dan bertanya-tanya di mana tes integrasi lebih keras dengan desain kami?

Kami menulis tes yang lebih terintegrasi, yang lebih besar dan tidak mengkritik desain kami sama kerasnya dengan microtests


3
Pertanyaannya membingungkan. "dengan cara mana tes integrasi lebih keras" ... "tes terintegrasi, yang lebih besar dan tidak mengkritik desain kita sebagai keras" - bagaimana sekarang?
AnoE


"tes integrasi"! = "tes terintegrasi". Aku tahu. Saya juga tidak suka, tapi itulah yang dimaksud kata-kata itu. "tes integrasi" = "tes yang memeriksa titik integrasi (tanpa mengintegrasikan hal-hal)", sementara "tes terintegrasi" = "(lebih besar) menguji yang mengintegrasikan berbagai hal dan memeriksa keseluruhan yang terintegrasi sebagai satu hal". Dengan cara ini, istilah-istilah ini saling bertentangan.
JB Rainsberger

Jawaban:


46

Microtests dapat membantu menghasilkan desain yang baik . Dengan menulis tes kecil yang bagus, Anda dengan sengaja menguji sejumlah kecil kode dan mengisi celahnya dengan benda tiruan . Hal ini menyebabkan kopling rendah (hal-hal yang tidak saling bergantung) dan kohesi tinggi (hal-hal yang dimiliki bersama tetap bersama). Dengan begitu, ketika Anda kembali dan melakukan perubahan, mudah untuk menemukan apa yang bertanggung jawab atas apa yang Anda cari dan Anda cenderung tidak akan merusak barang-barang dalam melakukan perubahan. Ini tidak akan menyelesaikan semua desain Anda tetapi ini bisa membantu.

Dalam konteks ini, JB Rainsberger mencatat bahwa jika Anda mengalami kesulitan menulis tes unit, Anda mungkin memiliki masalah dengan desain Anda yang menyebabkan kesulitan, dan dengan demikian tes mengkritik desain secara implisit. Dia berpendapat bahwa ini adalah hal yang baik, karena tanpa tes kecil membantu menjaga arsitektur Anda sejalan, mudah untuk menyimpang dari pola desain yang baik - yang tes terpadu tidak akan ditangkap.

Pembaruan : seperti yang dicatat Rainsberger di bawah ini, ia tidak bermaksud microtests untuk menjadi identik dengan tes unit. Dia juga memberikan jawaban terperinci yang dapat memberi Anda wawasan yang lebih dalam tentang apa yang ia komunikasikan.


2
Saya setuju dengan jawaban Anda pada prinsipnya, tetapi bukan cara Anda mengartikulasikannya. Seseorang yang menanyakan pertanyaan khusus ini tidak mungkin tahu apa arti istilah "mengejek," "menyambung" dan "kohesi", dan Anda belum mendefinisikan istilah-istilah itu dalam jawaban Anda.
Robert Harvey

3
Itu lebih baik, tetapi Anda memberikan unit test lebih banyak kredit daripada yang saya pikir seharusnya. Tes unit sebagian besar menginformasikan testabilitas kode Anda. Tidak terlalu jelas apakah membuat kode Anda dapat diuji secara otomatis memberikan karakteristik kohesi dan kopling yang lebih baik, meskipun tentu saja itu merupakan pengaruh positif. Juga, saya pikir Anda "kohesi tinggi" bingung dengan "prinsip tanggung jawab tunggal;" kohesi berarti "hal-hal yang menjadi bagian bersama" (lihat artikel Wikipedia ).
Robert Harvey

10
Akhirnya, "tes mikro" bukan istilah yang disukai. Saya suka ketika blogger membuat istilah teknis mereka sendiri.
Robert Harvey

2
@RubberDuck: Microtests (Tentang 16.900 hasil) vs Tes Unit (Tentang 193.000.000 hasil) . Bahkan tidak dekat. Bahkan jika Anda tumbuk unit dan tes bersama Anda masih mendapatkan 14 juta hasil.
Robert Harvey

5
Tolong jangan menyamakan "microtest" dan "unit test" (lihat jawaban saya untuk beberapa detail); jika tidak, saya merasa Anda mengerti apa yang saya coba gambarkan.
JB Rainsberger

28

Versi yang sangat singkat: tes yang lebih kecil, karena mereka menjalankan bagian yang lebih kecil dari sistem, secara alami membatasi apa yang dapat ditulis oleh programmer, dan karenanya ini menciptakan peluang untuk umpan balik yang lebih tajam (lebih mudah untuk diperhatikan / sulit diabaikan). Izinkan saya menambahkan bahwa ini tidak selalu mengarah ke desain yang lebih baik, tetapi malah menciptakan peluang untuk melihat risiko desain lebih cepat.

Pertama, untuk memperjelas, ketika saya mengatakan "microtest", maksud saya "tes kecil" dan tidak lebih. Saya menggunakan istilah ini karena saya tidak bermaksud "unit test": Saya tidak ingin terlibat dalam perdebatan tentang apa yang merupakan "unit". Saya tidak peduli (setidaknya tidak di sini / sekarang). Dua orang mungkin akan setuju dengan lebih mudah pada "kecil" daripada pada "unit", jadi saya secara bertahap memutuskan untuk mengadopsi "microtest" sebagai istilah standar yang muncul untuk ide ini.

Tes yang lebih besar, tes berarti yang menjalankan bagian sistem yang lebih besar dalam bagian "aksi" mereka, cenderung tidak mengkritik desain sejelas atau selengkap tes yang lebih kecil. Bayangkan himpunan semua basis kode yang dapat lulus kelompok tes tertentu, yang berarti bahwa saya dapat mengatur ulang kode dan masih akan melewati tes tersebut. Untuk tes yang lebih besar, set ini lebih besar; untuk tes yang lebih kecil, set ini lebih kecil. Dengan kata lain, tes yang lebih kecil membatasi desain lebih banyak, sehingga lebih sedikit desain yang dapat membuatnya lulus. Dengan cara ini, microtests dapat lebih banyak mengkritik desain.

Saya mengatakan "lebih keras" untuk menyulap citra seorang teman yang memberi tahu Anda secara langsung apa yang tidak ingin Anda dengar, tetapi perlu didengar, dan siapa yang berteriak pada Anda untuk menyampaikan urgensi sedemikian rupa sehingga orang lain mungkin tidak merasa nyaman perbuatan. Tes terintegrasi, di sisi lain, tetap diam dan hanya mengisyaratkan masalah sebagian besar ketika Anda tidak lagi punya waktu atau energi untuk mengatasinya. Tes terintegrasi membuatnya terlalu mudah untuk menyapu masalah desain di bawah karpet.

Dengan tes yang lebih besar (seperti tes terintegrasi), kebanyakan programmer cenderung mendapat masalah melalui kecerobohan: mereka memiliki cukup kebebasan untuk menulis kode kusut yang entah bagaimana melewati tes, tetapi pemahaman mereka tentang kode itu memudar dengan cepat saat mereka pindah ke tugas berikutnya , dan lainnya mengalami kesulitan yang tidak semestinya membaca desain yang kusut. Di sinilah letak risiko mengandalkan tes terintegrasi. Dengan tes yang lebih kecil (seperti microtests), kebanyakan programmer cenderung mendapat masalah melalui over-spesifikasi: mereka terlalu membatasi tes dengan menambahkan rincian yang tidak relevan, biasanya dengan menyalin / menempel dari tes sebelumnya, dan dengan demikian mereka relatif cepat melukis diri mereka sendiri ke sudut. Kabar baik: Saya merasa jauh lebih mudah dan aman untuk menghapus perincian yang tidak perlu dari tes beberapa jam atau hari setelah saya menulisnya daripada saya menemukannya untuk memisahkan kode produksi yang kusut berbulan-bulan hingga bertahun-tahun setelah saya menulisnya. Semakin banyak kesalahan, menspesifikasikan secara berlebihan menghasilkan kerusakan yang lebih jelas dan lebih cepat, dan programmer lansiran melihat sebelumnya bahwa mereka perlu memperbaiki beberapa hal. Saya menganggap ini sebagai kekuatan: Saya memperhatikan masalah sebelumnya dan memperbaikinya sebelum masalah tersebut mencekik kemampuan kita untuk menambahkan fitur.


Apa yang Anda lakukan tentang masalah yang unit tes lebih bergantung pada ejekan mereka daripada pada kode nyata, yang mengarah ke masalah tes yang tampaknya lulus tetapi tidak benar-benar berfungsi karena tidak ada yang menjaga ejekan sesuai dengan kenyataan.
Zan Lynx

@ ZanLynx Saya sudah menulis tentang ini panjang lebar. Mulai di sini: blog.thecodewhisperer.com/series#integrated-tests-are-a-scam
JB Rainsberger

9

Maksudnya desain perangkat lunak yang baik lebih baik diinformasikan oleh unit test daripada tes integrasi.

Inilah sebabnya. Tes unit menulis memaksa Anda untuk menulis kode yang dapat diuji unit. Kode unit-testable cenderung desain yang lebih baik daripada kode yang tidak memiliki unit test.

Tes integrasi tidak menginformasikan kode Anda dengan cara yang sama karena Anda hanya menguji lapisan luar perangkat lunak Anda, bukan antarmuka bagian dalam yang menghubungkan perangkat lunak Anda bersama-sama.

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.