Test yazdırırken “bu fonksiyona test ekle” demek başlangıç olabilir, fakat hangi hatayı yakalamak istediğinizi söylemek daha değerlidir. Anlamlı bir test, kodun bugün nasıl yazıldığını tekrar etmez; korunması gereken bir davranışı görünür hale getirir. Codex ile test hazırlarken önce bu davranışı ve başarısızlık örneğini seçebilirsiniz.
Testin koruyacağı kuralı belirleyin
Bir blogda yayın tarihi gelecekte olan yazılar ziyaretçiye gösterilmemeli olsun. Buradaki kural yalnızca bir sorgu koşulunun varlığı değildir. Geçmiş tarihli yayın görünür, taslak görünmez ve gelecekteki yayın zamanı gelene kadar listede yer almaz. Bu örnekler, uygulamanın iç düzeninden bağımsız bir beklenti kurar.
Kodun içindeki koşulu aynen teste kopyalamak hatalı mantığın iki yerde bulunmasına yol açabilir. Beklenen sonucu ürün kuralından üretin. Örneğin sabit bir “şimdi” zamanı seçerek ondan önceki, eşit ve sonraki tarihleri deneyebilirsiniz. Eşitlik sınırında ne olması gerektiği belirsizse önce bu kararı netleştirin.
Her uç durumu eklemek zorunda değilsiniz. Boş liste, tek öğe ve sınırdaki tarih bu davranış için anlamlı olabilir; alakasız rastgele girdiler testin değerini artırmayabilir. Senaryo seçimini gerçek riskle ilişkilendirmek, daha küçük ama daha güçlü bir test kümesi oluşturur.
Projenin mevcut test dilini kullanın
Yeni bir test aracı eklemeden önce depodaki benzer örneklere bakın. Test verisi nasıl hazırlanıyor, zaman nasıl sabitleniyor ve veritabanı nasıl temizleniyor? Mevcut yaklaşımı izlemek, yeni testin ekip tarafından okunmasını ve çalıştırılmasını kolaylaştırır. Yalnızca tek bir görev için paralel altyapı kurmak çoğu zaman gereksizdir.
Yayın listesinin gelecekteki yazıları gizleme davranışına test ekle. Mevcut test araçlarını ve veri hazırlama kalıplarını kullan. Geçmiş tarihli yayın, gelecekteki yayın ve taslak örneklerini kapsa. Zamanı sabit tut; test gerçek saate bağlı olarak değişmesin. Testin hangi kullanıcı kuralını koruduğunu ve gerçekten çalıştırılan sonucu bildir.
Bu prompt, test dosyasının adından daha önemli bilgileri verir. Başarı, yeni satırların bulunmasıyla değil yanlış davranış oluştuğunda testin başarısız olabilmesiyle ölçülür. Eski bir hatayı düzeltirken testin hata mevcutken kırılması, doğru şeyi kontrol ettiğini anlamak için güçlü bir kanıttır.
Test adını da kullanıcı kuralını taşıyacak şekilde seçin. “Liste çalışır” yerine “gelecekteki yayın kategori listesinde görünmez” ifadesi, hata çıktısında hemen anlam kazanır. Veri kurulumundaki adları aynı açıklıkla seçmek, başarısızlık sırasında hangi örneğin beklentiyi bozduğunu gösterir. İyi adlandırma yeni bir araç gerektirmez; fakat aylar sonra teste dönüldüğünde araştırma süresini belirgin biçimde azaltabilir ve beklentinin neden var olduğunu korur.
Gereksiz kırılganlığı azaltın
Bir testin her refactoring sonrasında değişmesi gerekiyorsa uygulama ayrıntılarına fazla bağlı olabilir. Kullanıcı açısından önemli olmayan nesne sırasını, özel metot adını veya gereksiz çağrı sayısını doğrulamak bakım maliyetini yükseltir. Beklentiyi mümkün olduğunca dış davranışa bağlayın.
Buna karşılık testin çok genel olması da sorun yaratır. “Sayfa başarılı yanıt verdi” kontrolü, gelecekteki yazının yanlışlıkla listelenmesini yakalamaz. Görünmesi gereken ve görünmemesi gereken içerikleri birlikte doğrulamak daha anlamlıdır. Aynı testte bütün uygulamayı sınamaya çalışmak yerine bir kuralı açıkça koruyun.
Son olarak test sonucunu koşullarıyla okuyun. Gerekli veritabanı bulunmadığı için atlanan test, başarılı test değildir. Çalıştırılamayan kontrolün nedeni açıkça belirtilmelidir. Testin nasıl çalışacağı ve neyi kanıtladığı anlaşılıyorsa, sonraki geliştirici de onu güvenle kullanabilir. İyi test çıktısı yalnızca yeşil bir işaret değil, korunmak istenen davranışın okunabilir bir örneğidir.
Kaynak: OpenAI’nin test görevi örnekleri.
