Bagaimana seseorang melakukan pengujian unit di mesin game?

23

Sangat memalukan, saya tidak pernah menulis unit test yang tepat, hanya program tes kecil yang tidak terorganisir yang kemudian akan saya buang setelah tes berhasil. Saya tidak benar-benar memiliki gagasan yang jelas tentang bagaimana pengujian unit harus dilakukan dalam proyek game. (Bahasa saya adalah C ++.)

Haruskah saya memiliki proyek terpisah untuk setiap subsistem di mesin saya dan tes yang terkait dengannya, dan kemudian memiliki proyek / solusi yang lebih besar yang membangun mesin yang sebenarnya? Katakan misalnya saya memiliki eventmodul di mesin saya; bagaimana saya harus mengatasinya?

c++ software-engineering unit-testing

— Paul Manta
sumber

pertanyaan menarik, ketika Anda mengembangkan mesin Anda, cukup mudah untuk menguji fungsionalitas, tetapi bagaimana dengan proyek besar dalam uji coba game?

— Yevhen

2

Bukan hal yang memalukan: tes unit tidak secara otomatis merupakan hal yang baik.

— o0 '.

1

Jika Anda belum pernah mencoba menggunakan unit test, itu pasti memalukan.

— Kristopher Johnson

18

Pertama, Anda membutuhkan kerangka kerja unit testing. Di masa lalu saya telah menggunakan UnitTest ++ dan Google Test . Yang pertama sangat ringan dan yang terakhir lebih disukai tetapi agak lebih rumit. Terintegrasi dengan baik dengan Google Mock jika Anda membutuhkan hal semacam itu. Tentu saja ada banyak pilihan lain: lihat daftar ini (oleh penulis akhirnya dari UnitTest ++) dan Wikipedia misalnya.

Pengujian unit adalah tentang penulisan tes terfokus untuk menekankan bit kode independen yang terisolasi ("unit") di bawah berbagai skenario. Meskipun dalam beberapa kasus Anda dapat menguji semuanya, biasanya tidak praktis untuk mencapai cakupan 100% dan, terutama dalam game, bisa sangat sulit - dapat diperdebatkan apakah unit menguji output renderer Anda dengan cara apa pun yang berarti, bermanfaat, atau uji unit "benar" bagaimanapun.

Penting untuk diingat bahwa setiap pengujian (otomatis) lebih baik daripada tidak ada pengujian (otomatis). Jadi, Anda tidak boleh terlalu menekankan fakta bahwa tes Anda bukan "tes unit sejati" dan bangga bahwa Anda hanya memiliki tes. Kerangka kerja pengujian unit biasanya berguna untuk membangun lebih longgar, "non-unit" tes juga karena mereka mencakup fungsionalitas untuk tes kemasan dan melaporkan kegagalan secara seragam.

Saya akan mendorong Anda untuk menghidupkan kembali tes lama Anda dan membuatnya menjadi proyek uji menggunakan salah satu kerangka kerja yang tersedia - sesuatu yang dapat Anda jalankan dengan mudah dari waktu ke waktu (atau secara otomatis sebagai bagian dari rilis atau integrasi build) yang menjalankan semua tes Anda. Menulis tes baru untuk bit kode karena menjadi jelas akan berguna bagi Anda, misalnya jika Anda menemukan bug halus yang bisa Anda deteksi dengan tes, Anda dapat menambahkan satu untuk menangkap setiap regresi yang mungkin Anda buat di masa depan.

Anda mungkin akan menemukan bahwa sebagian besar kode utilitas tingkat rendah yang sesuai dengan pengujian unit, dalam gim. Tidak apa-apa - itu kode dasar yang dapat mengganggu banyak lapisan yang lebih tinggi jika rusak.

Anda tidak akan pergi ke purgatory programmer karena tidak memiliki tes untuk setiap fungsi kecil dan gerbang logis dalam basis kode Anda, jadi jangan menghabiskan lebih banyak waktu daripada yang Anda butuhkan untuk menulis tes. Jika Anda harus berpikir lebih keras atau menghabiskan lebih banyak waktu untuk menulis tes untuk sebuah modul daripada yang Anda butuhkan untuk membuat modul, Anda mungkin membuang-buang waktu. Pengujian unit - pengujian pada umumnya - adalah alat yang Anda pelajari untuk digunakan secara tepat untuk membantu Anda, bukan tugas yang harus Anda lakukan untuk semuanya.

— Josh
sumber

3

If you have to [...] spend significantly more time writing the tests [...] than it took you to author the module... Maka modul Anda terlalu kompleks. Sederhanakan sekarang, Anda akan berterima kasih pada diri sendiri di masa depan!

— Jess Telford

3

@ Jess. Modul yang sulit untuk diuji tidak perlu disederhanakan. Ada banyak area di mana pengujian unit tidak menggunakan waktu dengan baik. Ini termasuk grafik, di mana output bisa sangat bervariasi dan masih dapat diterima; kode yang tidak mungkin berubah di masa mendatang; atau kode di mana jenis abstrak, desain yang digabungkan yang akan diperlukan untuk memfasilitasi pengujian unit jauh lebih jelek, lebih rentan kesalahan, kurang berkinerja, atau kurang intuitif.

— Casey Rodarmor

@ prodarmor - setuju. Ada skala geser dari apa yang pantas dan apa yang tidak. Seperti halnya semua jenis jawaban ini, satu ukuran tidak cocok untuk semua :)

— Jess Telford

Untuk UnitTest ++, buka github.com/unittest-cpp/unittest-cpp . Segala sesuatu yang lain sudah ketinggalan zaman.

— Markus

7

Ada serangkaian posting blog yang luar biasa tentang penggunaan TDD dan pengujian unit untuk pengembangan game di sini: http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

— Muttley
sumber

4

"Unit" adalah bagian terkecil dari kode yang dapat diuji, biasanya satu fungsi atau kelas. Tes unit adalah bagian kode lain yang melatih unit kode untuk memastikannya berperilaku sebagaimana dimaksud. Unit kode tunggal mungkin memiliki banyak pengujian, untuk mencakup semua kasus.

Biasanya, tes tidak termasuk dalam bangunan utama proyek. Sebaliknya, ada konfigurasi build terpisah untuk pengujian yang mencakup semua kode pengujian dan menghasilkan program yang menjalankan semua pengujian dan melaporkan hasilnya. Kerangka pengujian akan menyediakan semua perancah untuk ini dan direkomendasikan, meskipun tidak sepenuhnya diperlukan. Jika Anda benar-benar baru dalam pengujian, Anda mungkin lebih baik pada awalnya menulis rig pengujian ad-hoc Anda sendiri, untuk memastikan Anda memahami semua yang terjadi.

Tutupi sebanyak mungkin kode dengan tes, prioritaskan kode yang tidak Anda yakini, atau kode yang rapuh dan mungkin rusak oleh perubahan di masa mendatang. Anda harus sering menjalankan tes, idealnya setelah setiap perubahan kode.

— jedediah
sumber