Apakah itu? Mungkin. Pendapat saya adalah bahwa itu akan membuat sangat tidak cocok untuk perangkat lunak hiburan pada umumnya, meskipun mungkin bekerja dengan baik untuk perpustakaan tingkat rendah.
EDIT: Inilah beberapa justifikasi untuk pendapat saya.
Wikipedia mendefinisikan BDD sebagai teknik yang "mendorong kolaborasi antara pengembang, QA dan peserta non-teknis atau bisnis dalam proyek perangkat lunak." Ini sudah terdengar seperti ide yang buruk karena permainan berbeda dari sebagian besar perangkat lunak karena mereka tidak dirancang sebagai alat untuk memenuhi kebutuhan spesifik untuk 'peserta non-teknis atau bisnis', tetapi merupakan karya kohesif yang dirancang secara luas untuk menghibur. Ada penekanan pada "perilaku perangkat lunak yang diinginkan" tetapi game jarang memiliki 'perilaku perangkat lunak yang diinginkan' kecuali pada tingkat teknis. Pasti ada gunanya memeriksa bagian kode itu, tetapi tidak dengan pengguna akhir, karena mereka tidak akan pernah melihatnya.
Tapi mari kita asumsikan bahwa Anda ingin membuang barang-barang pemangku kepentingan manusia dan hanya menggunakan BDD untuk menegakkan kontrak antara modul kode yang berbeda, yang sejauh yang saya bisa lihat tidak jauh berbeda dari pengembangan yang digerakkan oleh tes normal, yang saya juga anggap buruk. cocok untuk gim, karena alasan berikut.
Tes berguna untuk memeriksa bahwa peristiwa terpisah terjadi ketika diharapkan. Ini bekerja dengan baik dalam pemrograman yang digerakkan oleh peristiwa, yaitu. sebagian besar dunia perangkat lunak, di mana tindakan dilakukan, beberapa output dihasilkan, dan kemudian Anda hanya memverifikasi bahwa tindakan dan hasilnya cocok. Namun, perangkat lunak game biasanya merupakan simulasi, di mana suatu tindakan tidak memiliki hasil yang terpisah tetapi perubahan terus-menerus di negara dunia. Jika pemain saya yang tersembunyi mengeluarkan suara, saya mungkin ingin memeriksa apakah AI memburu saya. Jadi, saya bisa membuat tes untuk memastikan bahwa AI dalam keadaan 'berburu' setelah kebisingan dibuat, dan itu hebat. Tapi bagaimana saya tahu perburuan itu berhasil? Anda tidak dapat memeriksanya secara instan - Anda hanya dapat mengamatinya seiring berjalannya waktu.
Selain itu, pendekatan pengujian pertama dapat menciptakan rasa aman palsu, dan membuat orang percaya kode lebih baik daripada yang sebenarnya.
def check_dice_roll_in_range():
d = new Dice()
assert(d.roll() between 1 and 6)
class Dice:
def roll():
return 4
Karena hasil tes dapat memberikan hasil positif palsu, Anda tidak pernah bisa lepas dari kebutuhan dasar untuk memeriksa kode itu sendiri. Tetapi jika kode itu sendiri diperiksa secara memadai, tes ini mengambil kepentingan sekunder. Inilah sebabnya, menurut pendapat saya, tes terbaik digunakan setelah acara, untuk menguji perbaikan bug.
Saya tidak akan berdebat bahwa tidak pernah ada manfaat dalam pengujian itu, ketika objek X dan Y bekerja bersama, hasil yang Anda dapatkan adalah seperti yang diharapkan. Masalahnya adalah apakah Anda menggunakan cara paling efektif untuk memverifikasi ini. Metode dapat mencakup verifikasi formal, tinjauan kode, metode uji-pertama, metode uji-terakhir, pengujian kotak hitam QA tradisional, atau cukup menggunakan kode seperti yang diharapkan dan mengamati hasilnya. Dua opsi terakhir secara mengejutkan efektif sebagian besar waktu, karena meskipun terdengar seperti mereka kurang keras, sebagian besar bug ditemukan selama penggunaan khas, dan memahami bug dalam konteks alaminya kadang-kadang bisa lebih mudah daripada memahaminya dalam tes buatan memanfaatkan. Selain itu,
Jadi, secara ringkas, saya pikir pengembangan yang digerakkan oleh tes belum tentu merupakan pilihan yang bagus untuk perangkat lunak, bahwa tes saja tidak pernah cukup untuk memastikan kualitas perangkat lunak (dan dengan demikian waktu yang dihabiskan untuk menulisnya harus dibandingkan dengan penggunaan alternatif pada waktu pengembang itu), bahwa permainan adalah pertandingan yang sangat buruk untuk kasus pengujian otomatis, dan bahwa permainan tersebut sangat cocok untuk metode pengembangan yang terlihat menekankan 'nilai bisnis' dan 'pengujian penerimaan'.
(Semoga itu adalah jawaban yang lebih baik, bahkan jika Anda tidak setuju dengan poin saya.)