Bagaimana saya bisa menguji output rendering unit?

Saya telah merangkul Test-Driven Development (TDD) baru-baru ini dan memiliki dampak yang luar biasa pada hasil pengembangan saya dan ketahanan basis kode saya. Saya ingin memperluas pendekatan ini ke beberapa pekerjaan rendering yang saya lakukan di OpenGL, tetapi saya tidak dapat menemukan pendekatan yang baik untuk ini.

Saya akan mulai dengan contoh nyata sehingga kita tahu hal-hal apa yang ingin saya uji; katakanlah saya ingin membuat unit cube yang berputar pada beberapa sumbu, dan saya ingin memastikan bahwa, untuk beberapa jumlah frame, setiap frame dirender dengan benar.

Bagaimana saya bisa membuat test case otomatis untuk ini? Lebih disukai, saya bahkan dapat menulis test case sebelum menulis kode apa pun untuk merender kubus (sesuai praktik TDD biasa). Di antara banyak hal lain, saya ingin memastikan bahwa ukuran, lokasi, dan orientasi kubus adalah benar di setiap frame yang diberikan. Saya bahkan mungkin ingin memastikan bahwa persamaan pencahayaan di shader saya benar di setiap frame.

Satu-satunya pendekatan yang sangat berguna untuk ini yang saya temui melibatkan membandingkan hasil yang diberikan dengan keluaran referensi, yang umumnya menghalangi praktik TDD, dan sangat rumit.

Saya dapat melanjutkan tentang persyaratan lain yang diinginkan, tetapi saya khawatir yang sudah saya sebutkan di luar jangkauan.

Ini sepertinya aplikasi kerangka kerja Tes Persetujuan yang bagus atau semacamnya.

Seperti yang dinyatakan dalam komentar, Anda masih akan memiliki masalah dengan false positive, jika Anda menyetujui output buruk, tetapi ini setidaknya akan memberi tahu Anda ketika output telah berubah secara signifikan.

Karena Anda menggunakan OpenGL, saya berasumsi bahwa persetujuan tidak akan bekerja untuk Anda secara langsung, tetapi idenya baik. Cukup periksa hash file dan jika berbeda, tunjukkan kegagalan pada penampil diff yang sesuai (seperti program gambar diff). Jika Anda menyetujui versi baru, perbarui file "disetujui" untuk mencocokkan hasil baru.

Saya tidak tertarik dengan bisnis gim, jadi harap tahan persepsi yang bodoh dan naif

Bagi saya, menulis tes yang membandingkan gambar yang diberikan sepenuhnya tidak benar-benar unit test, tetapi tes integrasi penuh , karena semuanya harus bekerja dengan baik untuk menjalankan tes yang sukses.

Bagaimana dengan lapisan menengah di mana Anda dapat memeriksa apakah semuanya baik-baik saja? Ada dua hal yang muncul di benak saya:

1. Jangan menggambar langsung, tetapi keluarkan aliran perintah yang diubah menjadi rendering panggilan. Aliran perintah dapat diperiksa kebenarannya. Ini bukan tes ujung ke ujung, tetapi Anda inginkan tes unit , bukan tes integrasi penuh.

2. Ini benar-benar variasi pada 1. Bungkus OpenGL, tangkap semua panggilan untuk itu, lepaskan ini ke apa yang benar-benar ingin Anda uji, dan periksa apakah hasilnya masih cocok. Pembungkus OpenGL dapat melakukan pemeriksaan sendiri jika dikonfigurasi dengan benar, dan berubah menjadi tiruan .

Masalahnya adalah bahwa mesin 3d tidak diperlukan untuk menampilkan gambar bit-for-bit yang tepat. Beberapa kelonggaran ditoleransi selama artefak yang disebabkan olehnya tidak terlihat oleh pemirsa. Tekstur 1% lebih gelap dari yang diharapkan biasanya bukan masalah serius ... biasanya. Dalam beberapa kondisi mungkin artefak visual. Dan itulah masalahnya: Sulit untuk menilai untuk pengujian otomatis mana artefak yang akan diperhatikan oleh pemirsa manusia dan mana yang tidak. Namun, tes otomatis dapat digunakan untuk pemeriksaan kewarasan sederhana bila digunakan pada geometri yang sangat sederhana.

Yang bisa Anda lakukan adalah merender beberapa adegan sederhana dan kemudian membandingkan gambar yang dihasilkan dengan render referensi. Render referensi itu dapat berasal dari mesin grafis lain atau menjadi tangkapan layar sebelumnya dari mesin yang sama (pengujian regresi).

Ketika beberapa tes gagal setelah perubahan ke mesin grafis, penguji manusia harus membandingkan output ke gambar referensi dan menilai sendiri jika output baru terlihat sama baiknya dengan sebelumnya (atau bahkan lebih baik). Ketika itu masalahnya, tes harus diubah untuk dibandingkan dengan output baru yang lebih baik.

Hal lain yang dapat Anda periksa secara otomatis adalah persyaratan kinerja. Salah satu persyaratan seperti itu adalah bahwa selama demo berjalan sendiri (mensimulasikan urutan nyata dari permainan) frame-rate tidak boleh turun di bawah 40 Fps pada sistem pengujian. Ini adalah sesuatu yang dapat Anda uji secara otomatis. Yang tidak bisa Anda uji adalah renderingnya memuaskan. Tetapi Anda dapat menggunakan tes tersebut untuk mencegah pengembang mengembangkan game yang terlihat hebat tetapi tidak berjalan dengan baik pada sistem yang terjangkau hingga bertahun-tahun setelah diluncurkan (halo Crytek).