Godot Projelerinde Test Süreci: Web Geliştiricilerinden Farklı Noktalar

Web geliştiricilerinin test yazma ve çalıştırma konusunda edindiği alışkanlıklar, Godot projelerinde işe yaramıyor. Jest ile veritabanını mock’layan ya da Playwright ile tarayıcı akışlarını test eden bir geliştirici, Godot’a geçtiğinde karşılaştığı engellerden şaşkınlığa uğrayabilir.

Godot projeleri genellikle varsayılan bir test çerçevesiyle gelmediği için, web geliştiricilerinin alıştığı otomatik test döngüsü burada kırılıyor. Peki bu durumda neler değişiyor ve hangi araçlar geliştiricilere yardımcı olabilir?

Godot’un varsayılan test modu web geliştiricilerini şaşırtıyor

Web projelerinde genellikle ilk günden itibaren entegre edilmiş bir test çerçevesi bulunur. Create React App ile başlayan projelerde Jest otomatik olarak gelir. Vitest ise Vite projelerinde varsayılan olarak yüklüdür. Geliştirici, iş mantığı yazmaya başlamadan önce çalışan bir test ortamına sahip olur.

Ancak Godot projelerinde durum farklıdır. Proje sadece Godot editörü ve _ready() fonksiyonuyla başlar. Varsayılan bir test çerçevesi bulunmaz. Topluluk tarafından yaygın olarak kullanılan GUT (Godot Unit Testing) bir eklenti olarak manuel olarak kurulması gereken üçüncü taraf bir araçtır. Oldukça kullanışlı olsa da, web geliştiricileri için ilk karşılaşmada şaşırtıcı bir durumdur.

Başka bir seçenek olan GodotTestDriver ise entegrasyon testleri için tasarlanmıştır. Godot’un --headless modu da sahneleri penceresiz çalıştırmaya olanak tanır. Ancak hiçbiri varsayılan olarak yapılandırılmaz. Ayrıca headless modunda, Viewport.get_texture() gibi render bağımlı kodlar sessizce boş sonuçlar üretmektedir.

Sahne ağacının durumu testlerde görünmez kalıyor

Web testleri genellikle üç tür durumu ele alır: DOM, state yönetimi ve veritabanı. Tüm bu durumlar incelenebilir niteliktedir. Örneğin, screen.getByRole('button') ile butonlara erişilebilir, Redux state okunabilir ya da test veritabanından sorgular yapılabilir.

Godot’da ise dördüncü bir durum daha vardır: sahne ağacı. Düğümlerin (nodes) ebeveynleri, sinyallerin diğer düğümlerle bağlantıları ve AnimationTree içindeki parameters/playback gibi aktif durumlar bulunur. Bu durumların hiçbiri hata yığınında görülmez. Hiçbiri bir test veritabanında yer almaz. Örneğin, bir fonksiyonun sinyal yayınladığını doğrulayan bir birim testi yazabilirsiniz, ancak alıcı düğüm iki kare önce serbest bırakılmışsa oyun çalışmaz.

Web geliştiricisiyken yaşadığım en zorlayıcı sorunlardan biri, izole testlerin başarılı geçmesine rağmen, çalışma zamanında sahne ağacının durumundan kaynaklanan hataların ortaya çıkmasıydı. Test çalıştırıcı, hatanın meydana geldiği anda sahne ağacının nasıl göründüğünü bilmiyordu.

Bu noktada GodotTestDriver’ın Fixture sınıfı yardımcı olmaktadır. Bu sınıf, test sırasında sahne düğümlerini yönetir ve temiz bir şekilde kapatır. Ancak burada da geliştiricilerin saf fonksiyon testleri yerine, gerçek sahne davranışını test eden entegrasyon testleri yazmaları gerekmektedir. Çoğu oyun mantığı saf fonksiyonlar değildir.

AI ile üretilen Godot kodu çoğunlukla çalıştırılmadan gönderiliyor

2026 yılında yayınlanan SonarSource State of Code raporuna göre, AI ile üretilen kodlardaki hataların %60’ı "sessiz başarısızlıklar" olarak sınıflandırılıyor. Bu kodlar derlenebilir, doğru görünebilir ancak üretimde yanlış sonuçlar üretir. 2025 yılında yapılan Stack Overflow Developer Survey sonuçlarına göre geliştiricilerin AI çıktısına olan güveni %40’tan %29’a düşmüş durumda. Katılımcıların %66’sı en büyük sorun olarak "neredeyse doğru" kodları gösteriyor.

Web geliştiricileri için bu durum biraz can sıkıcı olabilir. Tür denetimi (type-check) bazı hataları yakalarken, başarısız testler daha fazlasını ortaya çıkarabilir. Kullanıcı için görülebilir hata genellikle 500 hatasıyla ve Sentry uyarısıyla sonuçlanır.

Ancak Godot geliştiricisi için aynı kod gönderilebilir ve hiçbir şeyin yanlış olduğu belli olmayabilir. Derleme başarılıdır. Editörde herhangi bir hata görünmez. Play düğmesine bastığınızda sahne yüklenir ve karakter hareket eder. Ardından ölüm animasyonunun oynamadığını fark edersiniz, çünkü sinyal serbest bırakılan bir düğüme bağlanmıştı. Hata yoktur. Log hattı yoktur. Oyun sadece biraz yanlıştır.

AI tarafından üretilen kodu Godot’a yapıştırıp editörde çalıştırmadan göndermek, doğrudan üretime gönderilen test edilmeyen bir PR’ye eşdeğerdir. Web geliştiricileri bunu asla yapmaz. Godot geliştiricileri ise sık sık yapar, çünkü mevcut araçlar bu süreci en kolay yol olarak sunmaktadır.

İşe yarayan çözümler

Bu farklılıkları kapatmanın birkaç yolu bulunmaktadır.

• AI çıktısını yapıştırmadan önce bir smoke test sahnesi çalıştırın. Projeyi açın, sahneyi açın ve F5’e basın. AI’nin yaptığı değişiklik düğüm referanslarını ya da sinyal bağlantılarını bozmuşsa, bunu çıktı panelinde saniyeler içinde göreceksiniz. Bu basit gibi görünse de çoğu geliştirici, AI/dev döngüsündeki çok sayıda bağlam değişikliği nedeniyle bunu atlamaktadır.

• GUT’u ekleyin ve sahne ağacına dokunan sistemler için entegrasyon testleri yazın. Godot’da saf fonksiyon testleri yeterli değildir. Bir sahneyi yükleyen, girdileri ateşleyen, kareyi ilerleten ve sonuç durumunu doğrulayan testler yazmanız gerekir. GUT, add_child_autofree() ve sinyalleri beklemek için await anahtar sözcüğüyle bu süreci destekler.

• AI araçlarını sadece editörle değil, motorla entegre edin. Çoğu AI kodlama aracı sadece metin dosyalarını düzenler ve durur. Sahne ağacına erişimi yoktur, Play düğmesine basamazlar ve Godot çıktı panelini okuyamazlar. Bununla birlikte, giderek artan sayıda araç (örneğin Godot’a özel Ziva projesi) AI ajanını doğrudan motorla entegre eder. Bu sayede kodu yazan aynı model, sahneyi çalıştırabilir, çıktıyı izleyebilir ve bir sinyal ateşlenmediğinde tepki verebilir. Bu, "kod doğru görünüyor" ile "kod çalışıyor" arasındaki boşluğu kapatan süreçtir.

• Headless CI’yi başlangıç noktası değil, hedef olarak görün. Godot projelerinde ilk günden itibaren headless CI kurmak mümkün değildir. Bu normaldir. Öncelikle Play düğmesine basıp bir smoke test sahnesi çalıştırarak başlayın. Ardından testleri --headless modunda CI çalıştırıcısında çalıştırmayı hedefleyin. Web geliştiricileri için bu sıra tersine çevrilmiş durumdadır; Godot’da genellikle smoke-test ilkedir.

Dürüst bir özet

Oyun geliştirme testleri, web uygulama geliştirme testlerinden daha karmaşıktır. Godot projelerinde başarılı olmak için, web geliştiricilerinin alıştığı otomatik test süreçlerini yeniden düşünmek ve oyun motorunun kendine has özelliklerine uygun yeni yaklaşımlar benimsemek gerekiyor. Sahne ağacı, sinyaller ve render bağımlı kodlar gibi unsurlar, test stratejilerini baştan aşağı değiştiriyor. Bununla birlikte, doğru araçlar ve küçük adımlarla, Godot projelerinde de güvenilir ve etkili testler oluşturmak mümkün hale geliyor.