Kazanimlar:
- Test piramidine uygun biçimde birim, entegrasyon ve UI testlerini yapay zeka ile üretip mutlu senaryonun yanında sınır ve hata durumlarını kapsatabilme
- Üretilen her testin gerçekten bir davranış doğruladığını denetleyerek boş/işe yaramaz testleri ve şişirilmiş kapsamı ayıklayabilme
- Yapay zekaya kodun ne yapması gerektiğini söyleyerek testin hatayı yakalamasını sağlama ve hatayı sabitlemesini önleme
Kod yazmak işin yarısıdır; o kodun doğru çalıştığını kanıtlamak diğer yarısıdır. Mobil uygulamalar yüzlerce farklı cihaz, ekran boyutu, işletim sistemi sürümü ve kullanıcı davranışıyla karşılaşır. Bunların hepsini elle test etmek imkânsızdır; bu yüzden otomatik test (kodun kodu test etmesi — insan tıklamadan çalışan sınama) mobil kalitenin bel kemiğidir. YZ, test yazımında olağanüstü verimlidir çünkü test yazmak tam da onun sevdiği türden kalıp işidir: belirli bir davranışı, belirli girdiler için doğrulamak. Bu ünitede birim testi, arayüz testi ve otomasyonu YZ ile hızlandırmayı, ama testin kalitesini insan gözüyle güvence altına almayı öğreneceğiz.
Test piramidi: neyi ne kadar test etmeli
Sağlıklı bir test stratejisi bir piramide benzer. Tabanda çok sayıda birim testi (unit test — tek bir fonksiyon veya sınıfı izole test eden hızlı sınama) bulunur; bunlar hızlı ve ucuzdur. Ortada daha az sayıda entegrasyon testi (birden çok parçanın birlikte çalışmasını test etme) yer alır. Tepede en az sayıda UI/uçtan uca test (kullanıcının yaptığı gibi ekranda tıklayarak yapılan test) vardır; bunlar gerçekçidir ama yavaş ve kırılgandır. YZ her katmanda yardımcı olur ama en çok değer tabandadır: iş mantığının birim testlerini hızla üretir.
Test türü
Kapsam
Hız
YZ verimi
Birim testi
Tek fonksiyon/sınıf
Çok hızlı
Çok yüksek
Entegrasyon
Katmanlar arası
Orta
Yüksek
UI / uçtan uca
Tüm ekran akışı
Yavaş
Orta (kırılgan)
İpucu: YZ'ye "bu fonksiyon için testleri üret" derken sınır durumlarını (edge case) açıkça isteyin: boş girdi, null, negatif sayı, çok büyük değer, ağ hatası. YZ mutlu senaryoyu (happy path) kolay üretir; asıl hatalar sınırlarda saklanır ve orayı istemezseniz atlar.
YZ ile test yazımının adımları
- Test edilecek davranışı tanımlayın. "Bu fonksiyon şu girdiye şu çıktıyı vermeli."
- Çerçeveyi belirtin. Android'de JUnit + MockK, iOS'ta XCTest, UI için Espresso (Android) veya XCUITest (iOS).
- Sınır durumlarını isteyin. Mutlu senaryo + hata + sınır değerler.
- Sahte nesneleri (mock) yönetin. Ağ ve veritabanı gibi dış bağımlılıklar test için taklit edilir (mock — gerçek servis yerine kontrollü sahte).
- Testi çalıştırın ve doğrulayın. Test geçiyor mu, gerçekten anlamlı bir şey mi doğruluyor?
Beşinci adım kritiktir. YZ bazen "her zaman geçen" işe yaramaz testler üretir; örneğin hiçbir şey doğrulamayan veya kendi sahte verisini kendi kontrol eden test. Geçen test ile değerli test farklı şeylerdir.
Dikkat: YZ üretebildiği için testin doğru olduğu anlamına gelmez. Bazen YZ, kodun mevcut (belki hatalı) davranışını "doğru" kabul edip ona göre test yazar. Böyle test, hatayı yakalamak yerine sabitler. Testin ne beklediğini siz belirleyin; YZ'ye kodun ne yaptığını değil, ne yapması gerektiğini söyleyin.
Test kapsamı ölçüsü ve yanılgısı
Test kapsamı (code coverage — kodun yüzde kaçının testlerce çalıştırıldığı), faydalı ama aldatıcı bir ölçüdür. %90 kapsam, kodun %90'ının çalıştırıldığını gösterir; ama o satırların doğru çalıştığını doğrulandığını değil. Bir satırı çalıştırıp sonucunu kontrol etmeyen test kapsamı şişirir ama güvenlik vermez. Amaç yüksek sayı değil, anlamlı doğrulamadır. YZ ile kapsamı hızla yükseltebilirsiniz, ama her testin gerçekten bir davranışı sınadığından emin olun.
Üç mini vaka
Vaka 1 — Sınır durumu yakalandı. Bir bankacılık uygulamasında para transferi fonksiyonu için YZ'den testler istendi ve özellikle "negatif tutar" ve "bakiyeden fazla" senaryoları eklendi. Test, negatif tutarla transferin engellenmediğini ortaya çıkardı; bu, üretimde büyük bir güvenlik açığı olurdu. Bir satırlık kontrol eklenerek kapatıldı. Ders: sınır testleri en değerli testlerdir.
Vaka 2 — Sahte geçen test. Bir ekip, YZ'nin ürettiği 40 birim testiyle kapsamı %85'e çıkardı ve rahatladı. İnceleme sırasında testlerin çoğunun aslında hiçbir çıktıyı doğrulamadığı, sadece fonksiyonu çağırıp assertTrue(true) yazdığı görüldü. Kapsam yüksekti ama koruma sıfırdı. Testler elden geçirilip gerçek doğrulamalarla yeniden yazıldı. Ders: kapsam sayısı yalan söyleyebilir.
Vaka 3 — UI testi hızlandı. Bir e-ticaret ekibi, sepete ekleme akışının XCUITest senaryosunu YZ ile 20 dakikada yazdı; elle yazılsa yarım gün sürerdi. YZ ekran öğesi tanımlayıcılarını (accessibility identifier) tahmin etti; ekip bunları gerçek kodla eşleştirip düzeltti. Taslak hızı gerçek, ama tanımlayıcı doğrulaması insan işiydi.
Zayıf prompt / Güçlü prompt
Zayıf prompt:"Bu fonksiyona test yaz."
Güçlü prompt:"Bu Kotlin fonksiyonu için JUnit5 + MockK ile birim testleri üret.Fonksiyon: para transferi (miktar, kaynak, hedef).Test edilecek davranışlar (kodun ne YAPMASI gerektiği):- Geçerli transfer başarılı olmalı- Negatif veya sıfır tutar reddedilmeli- Bakiyeden fazla tutar reddedilmeli- Ağ hatası uygun exception fırlatmalıHer test tek bir şeyi doğrulasın, isimleri açıklayıcı olsun,dış servisi mock'la. Boş assertion yazma."
Kopyalanabilir şablonlar
Birim testi şablonu:"[Dil] için bu fonksiyona [JUnit/XCTest] birim testleri üret.Beklenen davranış: [ne yapmalı].Kapsa: mutlu senaryo, null/boş girdi, sınır değerler, hata durumu.Her test tek davranışı doğrulasın; anlamlı assertion kullan; mock'la.[kod]"
UI testi şablonu:"[Espresso/XCUITest] ile şu akışın UI testini yaz:[adım adım kullanıcı akışı].Ekran öğelerini kararlı tanımlayıcılarla (accessibility id) seç,metin yerine id kullan. Bekleme (wait) stratejisi ekle.Öğe id'lerini gerçek kodla eşleştirmemi hatırlat."
Test denetim şablonu:"Bu testleri incele:1) Gerçekten bir çıktı/davranış doğruluyor mu, boş mu?2) Sınır durumlarını kapsıyor mu?3) Kodun hatasını sabitliyor mu, yoksa doğru davranışı mı bekliyor?Zayıf testleri işaretle ve güçlendir. [testler]"
Kapsam iyileştirme şablonu:"Bu sınıfın test edilmeyen kısımlarını belirle ve anlamlı testler öner.Sadece kapsam sayısını değil, gerçek risk taşıyan yolları önceliklendir.[kod]"
Sık yapılan hatalar
- Sadece mutlu senaryoyu test etmek. Hatalar sınır durumlarında saklanır; onları açıkça isteyin.
- Boş/işe yaramaz test kabul etmek. assertTrue(true) türü testler kapsamı şişirir, koruma vermez.
- YZ'ye kodun ne yaptığını doğrulatmak. Test, kodun ne yapması gerektiğini beklemeli; yoksa hatayı sabitler.
- Kapsam sayısını amaç sanmak. %90 kapsam, %90 doğruluk demek değildir.
- UI testinde metne bağlanmak. Metin değişince test kırılır; kararlı tanımlayıcı (id) kullanın.
- Mock'ları yanlış kurmak. Gerçek servisi çağıran "birim testi" yavaş ve kırılgan olur.
Özetle
Test, mobil kalitenin bel kemiğidir ve YZ bu alanda çok verimlidir, özellikle birim testlerinde. Test piramidini izleyin: çok birim, orta entegrasyon, az UI testi. YZ'den mutlu senaryonun yanı sıra sınır durumlarını ve hata yollarını açıkça isteyin. Üretilen her testin gerçekten bir davranış doğruladığından emin olun; boş testler ve şişirilmiş kapsam yanıltıcıdır. En önemlisi, YZ'ye kodun ne yaptığını değil, ne yapması gerektiğini söyleyin ki test hatayı yakalasın, sabitlemesin.
Uygulama görevi
Bir iş mantığı fonksiyonu (örneğin indirim hesaplama veya form doğrulama) için "Birim testi şablonu"nu kullanarak YZ'den testler isteyin ve sınır durumlarını (boş, negatif, çok büyük) açıkça belirtin. Üretilen testleri çalıştırın, sonra "Test denetim şablonu" ile aynı testleri denetletin. En az bir boş/zayıf test bulup güçlendirin ve testlerin fonksiyonun gerçek bir hatasını yakalayıp yakalayamadığını (küçük bir bug ekleyerek) sınayın.
Kontrol listesi
- [ ] Test piramidine uygun katmanı seçtim (öncelik birim)
- [ ] Mutlu senaryonun yanında sınır ve hata durumlarını istedim
- [ ] Her testin anlamlı bir assertion içerdiğini doğruladım
- [ ] YZ'ye kodun ne yapması gerektiğini söyledim, ne yaptığını değil
- [ ] Kapsam sayısına değil, gerçek risk yollarına odaklandım
- [ ] UI testlerinde kararlı tanımlayıcı kullandım, metne bağlanmadım