Ortogonalitas unit test vs hasil unit test


14

Saya menulis unit test untuk sistem kemudi untuk gim video. Sistem memiliki beberapa perilaku (hindari area ini karena alasan A, hindari area ini karena alasan B, masing-masing menambahkan sedikit konteks pada peta wilayah. Fungsi terpisah kemudian mem-parsing peta dan menghasilkan gerakan yang diinginkan.

Saya mengalami kesulitan memutuskan bagaimana menulis unit test untuk perilaku tersebut. Seperti yang disarankan TDD, saya hanya tertarik pada bagaimana perilaku memengaruhi gerakan yang diinginkan. Misalnya, menghindari-karena-alasan-A harus mengakibatkan gerakan menjauh dari posisi buruk yang disarankan. Saya sebenarnya tidak peduli bagaimana atau mengapa perilaku itu menambah konteks pada peta, hanya saja gerakan yang diinginkan jauh dari posisi.

Jadi tes saya untuk setiap perilaku mengatur perilaku, membuatnya menulis ke peta, lalu menjalankan fungsi parsing peta untuk mengetahui gerakan yang diinginkan. Jika gerakan itu memenuhi spesifikasi saya maka saya senang.

Namun sekarang tes saya bergantung pada perilaku yang bekerja dengan benar, dan fungsi penguraian peta bekerja dengan benar. Jika fungsi parsing gagal, maka saya akan mendapatkan ratusan tes gagal daripada pasangan. Banyak panduan penulisan ujian menyarankan ini adalah ide yang buruk.

Namun jika saya menguji langsung terhadap output dari perilaku dengan mengejek peta, maka tentunya saya terlalu dekat dengan implementasi? Jika saya bisa mendapatkan gerakan yang diinginkan yang sama dari peta dengan menggunakan perilaku yang sedikit berbeda, maka tes harus tetap berlalu.

Jadi sekarang saya menderita disonansi kognitif. Apa cara terbaik untuk menyusun tes ini?


... tidak yakin ada jawaban ajaib. Pada dasarnya Anda menguji hal-hal yang dapat merusak. Jadi idealnya Anda entah bagaimana secara ajaib dapat mengetahui tes tingkat rendah mana yang sudah akan cukup dicakup oleh tes tingkat tinggi bahwa mereka tidak memerlukan tes unit tingkat rendah sendiri. Cara lain untuk melihatnya adalah: dari saat tes gagal hingga pengembang menyelesaikan masalah, berapa banyak waktu yang akan berlalu? Anda ingin waktu ini rendah. Jika Anda tidak memiliki unit, tetapi hanya tes fungsional yang sempurna (cakupan tingkat tinggi penuh), waktu itu masih terlalu tinggi. Coba gunakan itu sebagai panduan heuristik.
Calphool

Jawaban:


10

Di dunia ideal, Anda memang akan memiliki serangkaian tes unit ortogonal sempurna, semua pada tingkat abstraksi yang sama.

Di dunia nyata, Anda biasanya memiliki tes pada berbagai tingkat aplikasi, sehingga seringkali tes tingkat lebih tinggi menjalankan fungsi yang telah diuji dengan tes tingkat rendah khusus juga. (Banyak orang lebih suka memanggil tes tingkat tinggi seperti tes subsistem / integrasi daripada tes unit; namun mereka masih dapat berjalan pada kerangka pengujian unit yang sama, jadi dari sudut pandang teknis tidak ada banyak perbedaan.)

Saya tidak berpikir ini hal yang buruk. Intinya adalah meminta kode Anda diuji dengan cara terbaik yang sesuai dengan proyek Anda dan situasi Anda, bukan untuk mematuhi "cara ideal".


Saya kira poin utama penulis adalah apakah Anda harus menggunakan bertopik / mengejek atau implementasi nyata untuk tes tingkat yang lebih tinggi ini
SiberianGuy

2

Pengujian semacam ini adalah mengapa tiruan diciptakan. Gagasan utama: Anda menulis tiruan untuk objek Anda (peta, perilaku, karakter, ...), lalu menulis tes menggunakan tiruan itu alih-alih objek yang sebenarnya. Orang-orang kadang-kadang menyebut bertopik bertopik, dan saya percaya ada kata lain untuk keduanya.

Dalam kasus Anda, Anda akan menulis tiruan untuk peta kapan pun Anda perlu menguji perilaku, dan mengejek lainnya untuk perilaku kapan pun Anda ingin menguji peta. Mengejek Anda idealnya akan jauh lebih sederhana daripada perilaku sebenarnya yang Anda ejek, hanya memasukkan metode atau variabel yang benar-benar Anda butuhkan untuk tes itu. Anda mungkin harus menulis tiruan yang berbeda untuk setiap tes, atau Anda mungkin dapat menggunakan kembali beberapa tiruan. Apapun itu, mereka harus cocok untuk tes ini, dan tidak boleh mencoba menjadi seperti perilaku yang sebenarnya mungkin.

Jika Anda menyertakan beberapa contoh peta atau perilaku, mungkin seseorang dapat memberikan contoh ejekan yang dapat Anda tulis. Bukan saya, karena saya tidak pernah memprogram video game yang lebih maju daripada Pong, dan bahkan saat itu pun saya mengikuti sebuah buku, tetapi mungkin seseorang yang berpengalaman dalam pengujian unit dan pengembangan game.


0

Saya pikir Anda mencoba menguji hal-hal yang levelnya jauh lebih tinggi daripada unit.

Sebagian besar tes perilaku membutuhkan kecerdasan di baliknya, untuk mengetahui apakah itu berperilaku benar. Ini tidak dapat dengan mudah dilakukan dengan menggunakan pengujian otomatis.


inilah sebabnya saya menyebutkan keputusan. Saya dapat dengan mudah menulis unit test kecil untuk menguji setiap baris kode dalam suatu perilaku, dan telah dilakukan, tetapi itu tergantung pada membaca output dari fungsi parsing peta. Tidak satu pun dari tes perilaku saya yang besar, masing-masing hanya menguji satu fungsi dari perilaku tersebut.
tenpn
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.