Strategi pengujian untuk game

Saya telah mewarisi game edukasi berbasis web. Selama setahun terakhir saya telah berupaya menstabilkan kode dan menambahkan fitur baru. Sebagian besar logika ada di front-end, jadi tes unit back-end, sementara membantu, mencakup persen kecil dari kode.

Permainan telah sampai pada titik di mana ia mulai menjadi kompleks. Ada dua mode yang berbeda untuk setiap game dan game berperilaku berbeda tergantung pada mode. Ada juga berbagai bendera yang memengaruhi bermain game.

Saya telah menjadi pengembang aplikasi selama 10+ tahun sekarang dan ini membingungkan saya. Dalam dunia perusahaan, suatu algoritma selalu berfungsi dengan cara yang sama. Saya akan menulis unit test untuk suatu algoritma, saya akan mengharapkan nilai 42 dan itu akan kesalahan jika saya tidak mendapatkan nilai itu.

Ketika datang ke permainan, saya tersesat. Bagaimana saya mengujinya? Saya memiliki penguji yang tersedia untuk saya. Saya dapat menghabiskan waktu menulis tes unit.

Penguji ... tidak bisa diandalkan. Mereka bukan yang terbaik dalam membasmi masalah dan saya belum memberi mereka arahan terbaik. Singkat menghabiskan satu ton waktu setiap siklus rilis menguji setiap permutasi dan kombinasi permainan, bagaimana saya harus menggunakannya sebagai sumber daya?

Tes unit tampaknya terbatas. Karena sebagian besar logikanya adalah javascript (dan saya mewarisi kode spaghetti), saya dapat menggunakan suite front-end seperti Mentimun atau selenium untuk memastikan fitur-fitur tertentu berfungsi.

Apakah itu strategi terbaik? Bagaimana perusahaan game menguji game?

Saya telah membaca pertanyaan " Pengembangan Didorong Tes untuk Permainan Kompleks " (antara lain di situs), tetapi tidak membahas apa yang saya cari. Saya meminta strategi, bukan contoh spesifik tentang cara menguji.

Dalam dunia perusahaan, suatu algoritma selalu berfungsi dengan cara yang sama. Saya akan menulis unit test untuk suatu algoritma, saya akan mengharapkan nilai 42 dan itu akan kesalahan jika saya tidak mendapatkan nilai itu.

Ini tidak jauh berbeda dalam game. Kehadiran dua mode dan beberapa flag dalam game yang sedang Anda kerjakan tidak mengubah apa pun: jika Anda mengambil mode tertentu dengan set flag tertentu, Anda masih akan mendapatkan nilai yang sama berulang kali saat menguji bagian dari kode sumber.

Dengan terlalu banyak mode dan bendera, permainan dapat dengan cepat menjadi sangat sulit untuk diuji, karena banyaknya varian yang mungkin. Untuk mengurangi risiko mengalami kesulitan ini sejak dini, Anda harus:

• Mock / stub sangat . Jaga agar bagian yang diuji kecil, dan tiru semua yang mereka andalkan.

  Jika mereka bergantung pada waktu, mengejek objek waktu untuk selalu memberikan hasil tertentu atau serangkaian hasil tertentu, terlepas dari waktu aktual.

  Jika mereka mengandalkan random(), mengejeknya untuk memberikan konstanta setiap saat.

• Refactor . Jika tes mulai terlalu rumit atau jika Anda melihat bahwa suatu kelas, untuk diuji, memerlukan dua belas argumen setelah Anda menerapkan Dependency Injection, sementara itu hanya membutuhkan dua sebelumnya, Anda perlu refactor kode.

• Mempertanyakan aturan bisnis aplikasi yang sebenarnya. Saya berhenti menghitung jumlah proyek yang hampir mustahil untuk diuji karena jumlah variasi yang berbeda yang dibutuhkan oleh persyaratan fungsional yang tidak perlu atau dipahami oleh orang lain — bahkan para pemangku kepentingan sekalipun.

  Ketika sebuah situs web e-commerce kecil membutuhkan sepuluh halaman untuk menjelaskan persyaratan fungsional yang digunakan untuk menentukan bagaimana harga pengiriman dihitung, seseorang seharusnya tidak memulai dengan menulis tes atau kode, tetapi sebaliknya, harus kembali ke para pemangku kepentingan dan bekerja bersama mereka untuk menghasilkan persyaratan waras .

Akhirnya, otomatisasi setiap pengujian . Penguji diperlukan untuk menemukan situasi di mana aplikasi gagal. Menggunakan penguji untuk mengeksekusi, lagi dan lagi, tindakan yang sama di setiap revisi adalah kontra-produktif dan tidak sopan penguji: pengujian regresi harus dilakukan oleh mesin, bukan orang. Orang-orang, di sisi lain, jauh lebih baik dalam menemukan kemungkinan bug. "Bagaimana jika saya ..." adalah salah satu teknik yang dapat mereka gunakan ("Bagaimana jika saya memasukkan beberapa megabytes data biner yang mengandung beberapa \ x00 ke dalam bidang yang menanyakan usia saya, dan melihat apa yang akan terjadi?"), tetapi pendekatan yang lebih formal dapat digunakan juga.