Menguji kode secara umum tidak mudah. Jika ya, kita sudah melakukannya sejak lama, dan tidak melakukan hal itu hanya dalam 10-15 tahun terakhir. Salah satu kesulitan terbesar selalu dalam menentukan bagaimana menguji kode yang telah ditulis secara kohesif, dan diperhitungkan dengan baik, dan dapat diuji tanpa melanggar enkapsulasi. Kepala sekolah BDD menyarankan agar kita memfokuskan hampir seluruhnya pada perilaku, dan dalam beberapa hal tampaknya menyarankan bahwa Anda tidak benar-benar perlu khawatir tentang perincian batin sedemikian besar, tetapi ini seringkali dapat membuat hal-hal yang cukup sulit untuk diuji jika ada. banyak metode pribadi yang melakukan "hal-hal" dengan cara yang sangat tersembunyi, karena dapat meningkatkan kompleksitas keseluruhan tes Anda untuk menangani semua hasil yang mungkin di tingkat yang lebih umum.
Mengejek dapat membantu sampai batas tertentu, tetapi sekali lagi cukup terfokus secara eksternal. Ketergantungan Injeksi juga dapat bekerja dengan sangat baik, sekali lagi dengan mengejek atau menguji ganda, tetapi ini juga dapat mengharuskan Anda mengekspos elemen baik melalui antarmuka, atau secara langsung, bahwa Anda mungkin lebih suka tetap tersembunyi - ini terutama benar jika Anda ingin memiliki tingkat keamanan paranoid yang bagus tentang kelas-kelas tertentu dalam sistem Anda.
Bagi saya, juri masih belum yakin apakah akan merancang kelas Anda agar lebih mudah diuji. Ini dapat menimbulkan masalah jika Anda merasa perlu memberikan tes baru sambil mempertahankan kode lawas. Saya menerima bahwa Anda harus dapat menguji segala sesuatu dalam suatu sistem, namun saya tidak suka gagasan mengekspos - bahkan secara tidak langsung - internal privat suatu kelas, hanya agar saya dapat menulis tes untuk mereka.
Bagi saya, solusinya selalu mengambil pendekatan yang cukup pragmatis, dan menggabungkan sejumlah teknik yang sesuai dengan setiap situasi tertentu. Saya menggunakan banyak tes ganda yang diwarisi untuk mengekspos sifat batin dan perilaku untuk pengujian saya. Saya mengejek segala sesuatu yang dapat dilampirkan ke kelas saya, dan di mana itu tidak akan mengganggu keamanan kelas saya, saya akan memberikan sarana untuk menimpa atau menyuntikkan perilaku untuk keperluan pengujian. Saya bahkan akan mempertimbangkan untuk menyediakan antarmuka yang lebih berdasarkan peristiwa jika itu akan membantu meningkatkan kemampuan untuk menguji kode
Di mana saya menemukan kode "yang tidak dapat diuji" , saya mencari tahu apakah saya bisa menolak untuk membuat hal-hal lebih dapat diuji. Di mana Anda memiliki banyak kode pribadi yang tersembunyi di balik layar, sering kali Anda akan menemukan kelas-kelas baru yang menunggu untuk dikeluarkan. Kelas-kelas ini dapat digunakan secara internal, tetapi seringkali dapat diuji secara independen dengan perilaku yang kurang pribadi, dan seringkali lapisan akses dan kompleksitasnya lebih sedikit. Namun satu hal yang harus saya hindari adalah menulis kode produksi dengan kode uji bawaan. Dapat tergoda untuk membuat " test lug " yang menghasilkan kengerian seperti itu if testing then ..., yang menunjukkan masalah pengujian yang tidak sepenuhnya didekonstruksi dan dipecahkan secara tidak lengkap.
Anda mungkin terbantu untuk membaca buku Pola Tes xUnit Gerard Meszaros , yang mencakup semua hal semacam ini dengan lebih rinci daripada yang bisa saya baca di sini. Saya mungkin tidak melakukan semua yang dia sarankan, tetapi itu membantu untuk memperjelas beberapa situasi tes rumit yang harus dihadapi. Pada akhirnya, Anda ingin dapat memenuhi persyaratan pengujian sambil tetap menerapkan desain pilihan Anda, dan membantu untuk memiliki pemahaman yang lebih baik tentang semua opsi agar dapat memutuskan dengan lebih baik di mana Anda mungkin perlu berkompromi.