Apa pengujian unit kotak hitam?

Saya baru-baru ini ujian akhir saya untuk kursus rekayasa perangkat lunak untuk program master saya dan salah satu pertanyaan pada ujian adalah sebagai berikut:

Unit Testing is considered:
a. White-box Testing
b. Black-box Testing
c. Either

Dalam 7 tahun pengalaman pengembangan perangkat lunak saya, pengujian unit selalu mengambil pendekatan kotak putih. Penguji selalu memiliki pengetahuan penuh tentang implementasi unit saat menulis tes. Pengujian black box selalu datang kemudian dalam bentuk integrasi, sistem, dan pengujian penerimaan.

Namun, jawaban yang benar untuk ujian (menurut profesor) adalah bahwa pengujian unit dapat berupa pengujian kotak putih atau hitam.

Saya telah melakukan beberapa penelitian, dan tampaknya banyak kasus "pengujian unit kotak hitam" digunakan untuk menggambarkan pendekatan uji-pertama di mana tes unit ditulis sebelum kode tersebut. Namun menurut saya ini masih pengujian kotak putih. Sementara implementasi belum ada, siapa pun yang menulis tes umumnya memiliki ide yang cukup bagus tentang bagaimana kode sumber akan diimplementasikan.

Dapatkah seseorang tolong jelaskan kepada saya bagaimana pengujian unit kotak hitam bekerja (jika itu benar-benar suatu hal) dan bagaimana hal itu berbeda dari pengujian unit kotak putih?

Profesor Anda benar: pengujian unit dapat berupa kotak hitam atau kotak putih. Perbedaannya kurang tentang apa yang diketahui penguji, tetapi lebih banyak tentang bagaimana Anda menghasilkan kasus uji.

Dengan pengujian kotak hitam, Anda hanya melihat antarmuka dan (jika ada) spesifikasi untuk komponen. Ketika suatu fungsi memiliki tanda tangan int foo(int a, int b), maka saya dapat segera menghasilkan beberapa test case hanya dengan menguji bilangan bulat yang menarik: nol, satu, minus satu, angka multi-digit, INT_MAX, INT_MAX - 1 dan seterusnya. Tes kotak hitam sangat bagus karena tidak tergantung pada implementasi. Tetapi mereka juga mungkin kehilangan kasus-kasus penting.

Dengan tes kotak putih, saya melihat implementasinya, yaitu kode sumber dan menghasilkan kasus uji dari itu. Sebagai contoh, saya mungkin ingin mencapai cakupan jalur 100% untuk suatu fungsi. Saya kemudian memilih nilai input sehingga semua jalur diambil. Tes kotak putih sangat bagus karena mereka dapat menggunakan sepotong kode, dengan kepercayaan diri yang jauh lebih baik daripada tes kotak hitam. Tetapi mereka mungkin hanya menguji detail implementasi, bukan perilaku yang sebenarnya penting. Dalam beberapa kasus, mereka jelas membuang-buang waktu.

Karena tes kotak putih berasal dari implementasi, maka hanya dapat ditulis setelahnya. Tes kotak hitam berasal dari desain / antarmuka / spesifikasi, dan karenanya dapat ditulis sebelum atau setelah implementasi. TDD bukanlah kotak hitam atau kotak putih. Karena semua perilaku pertama kali diekspresikan oleh tes dan kemudian kode minimal untuk perilaku tersebut diimplementasikan, hasil TDD dalam kasus uji serupa dengan tes kotak putih. Tetapi ketika kita melihat aliran informasi, tes TDD tidak berasal dari kode sumber, tetapi dari persyaratan eksternal. Oleh karena itu, TDD lebih seperti kotak hitam.

Jika Anda melakukan Pengembangan yang Didorong oleh Tes, maka secara teori semua pengujian unit Anda harus menjadi kotak hitam. Ini adalah "pendekatan ujian pertama" Anda. Anda menulis kontrak (antarmuka), menulis tes untuk kontrak itu, dan kemudian kontrak dipenuhi oleh implementasi. Oleh karena itu tes tidak tahu apa-apa, dan tidak tahu apa-apa, tentang implementasinya.

Lagi pula, ketika Anda menulis tes, apa yang Anda uji? Metode / fungsi publik.

Jika Anda menulis antarmuka untuk kelas, dan kemudian menulis tes, dan kemudian Anda tertabrak bus, orang yang menulis kelas saat Anda di rumah sakit harus dapat melakukannya dari antarmuka Anda, bukan? Dia seharusnya tidak harus membuangnya dan menulis antarmuka dan tes sendiri.

Di mana ini agak berantakan adalah ketika Anda perlu mengejek sesuatu yang tergantung pada implementasinya, tetapi jika Anda menemukan diri Anda dalam situasi di mana Anda mengejek sesuatu yang tidak pernah diekspos secara publik, maka Anda telah membuat kesalahan, dan Anda perlu lihat ke Dependency Injection et al . Karena itu saya berpendapat bahwa pengujian kotak putih, bukan hitam, harus menjadi pengecualian.

Pertimbangkan 'Pengujian di Toilet - Uji Perilaku Tidak Implementasi' , di mana implementasi kelas diubah tetapi tes harus tetap valid.

Namun, jika Anda perlu memastikan cakupan kode Anda sudah habis (yaitu pastikan semua jalur kondisional diuji dalam implementasi), maka Anda benar-benar perlu untuk pengujian kotak putih, karena satu-satunya cara Anda dapat mengetahui apa yang Anda miliki. path adalah dengan melihat path dalam implementasi.

Saya berpendapat bahwa semua tes unit yang ditulis dengan baik pada dasarnya adalah "kotak hitam". Tentu saya mungkin memiliki implementasi dalam pikiran ketika saya menulis tes, tetapi implementasi itu dapat berubah ketika saya refactor. Jadi tes seharusnya hanya menggunakan API publik selama pengujian untuk menguji fungsionalitas, bukan implementasi. Itu tidak peduli tentang detail implementasi, jadi pengujian kotak hitam.

Jika saya menulis tes yang mengakses aspek internal atau pribadi dari unit yang diuji, maka saya sedang menguji detail implementasi: Saya pengujian kotak putih. Tapi saya juga menulis tes rapuh yang mudah patah ketika implementasi diubah. Jadi tes kotak putih semacam itu adalah ide yang buruk dan harus dihindari.

Kesimpulan: jika Anda tes kotak putih dengan tes unit, Anda memiliki tes yang dibangun dengan buruk. Hanya back box test dengan unit test tersebut. Profesor Anda benar: itu bisa saja. Tetapi hanya jika dilakukan dengan buruk.

Saya baru saja dalam proses menulis unit test yang melakukan pengujian black-box. Artinya, saya menguji metode publik di kelas dan dengan implikasi dari logika pengujian hasil dalam metode pribadi yang mereka sebut.

Saya melakukan ini dengan mengubah input ke metode publik menjadi unit yang diuji dan menguji output yang diharapkan yang ditentukan atau dimutasikan oleh logika dalam metode pribadi yang mendukung, implementasi yang, "unit test" saya tidak perlu tahu apa-apa.

Jadi, tidak ada yang menghentikan Anda melakukan pengujian kotak hitam pada tes unit dan tes akan pecah jika seseorang mengacaukan penerapan logika pendukung tersembunyi. Bahkan, ini sepertinya pendekatan yang unggul, lebih efisien, daripada unit kotak putih menguji segala sesuatu di kelas demi hal itu. Saya dengan profesor.