Bagaimana tes integrasi mengkritik desain?

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

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.

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.

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.