Kazanimlar:
- Yapay zeka ile kararlı seçici (data-testid), açık bekleme ve gerçek kullanıcı sonucunu doğrulayan assert içeren sağlam UI test kodu üretebilme
- Kırılgan testlerden (kötü seçici, kör bekleme) kaçınıp testleri Page Object Model yapısında bakımı kolay hale getirebilme
- Üretilen her UI testini kodu bozarak sınayıp sahte-geçen testleri tespit ve düzeltebilme
Bir kullanıcının tarayıcıda yaptığı her tıklama, her form doldurma, her sayfa geçişi elle tekrar tekrar test edilemez — bu yüzden UI test otomasyonu (user interface — kullanıcı arayüzü; bu testler gerçek bir tarayıcıyı programla sürerek kullanıcı davranışını taklit eder) vardır. Selenium, Playwright ve Cypress bu işin en yaygın araçlarıdır. Yapay zeka (YZ), bu araçların kodunu yazmakta oldukça yeteneklidir: bir test senaryosunu tarif edersiniz, YZ size çalışabilir bir otomasyon betiği taslağı verir. Ama burada bu modülün merkez uyarısı yeniden devreye girer: YZ'nin ürettiği UI test kodu çoğu zaman "yeşil yanan ama yanlış şeyi doğrulayan" ya da rüzgârda sallanan kırılgan testler olabilir. İşiniz bu kodu çalıştırmak değil, gerçekten doğru şeyi sağlam biçimde doğruladığından emin olmaktır.
Bu ünitede YZ ile sağlam, bakımı kolay ve gerçekten doğrulayan UI testleri üretmeyi; kırılgan testlerden (flaky tests) kaçınmayı öğreneceksiniz.
Sağlam UI testinin üç direği
1. Doğru element seçici (locator). Bir test, sayfadaki elementi bulmak için bir seçici kullanır. YZ sık sık kırılgan seçiciler üretir: uzun XPath yolları (sayfa yapısına aşırı bağımlı adres), CSS sınıf adlarına dayalı seçiciler (tasarım değişince kırılır). Sağlam yol, geliştiricinin test için eklediği data-testid gibi kararlı özniteliklerdir. YZ'ye bunu açıkça dayatın.
2. Gerçek bekleme (explicit wait). UI testlerinin bir numaralı kırılganlık kaynağı zamanlamadır. Sabit sleep(3) (kör bekleme) kötü pratiktir: bazen yetmez, bazen boşa zaman harcar. Doğrusu, "şu element görünene kadar bekle" diyen açık bekleme (explicit wait) kullanmaktır. Playwright bunu büyük ölçüde otomatik yapar; Selenium'da açıkça istemelisiniz.
3. Anlamlı doğrulama (assertion). Test, kullanıcının gerçekten göreceği sonucu doğrulamalı — sadece "sayfa yüklendi" değil, "sipariş numarası ekranda göründü" gibi. YZ'nin ürettiği testte assert yoksa veya önemsizse, o test sahte-geçiş üretir (1. ünite).
Dikkat: YZ'nin ürettiği UI testini ilk gördüğünüzde en çok üç şeyi kontrol edin: seçiciler kararlı mı (data-testid), beklemeler açık mı (kör sleep yok), ve assert gerçek kullanıcı sonucunu mu doğruluyor? Bu üçü tamamsa test muhtemelen sağlamdır.
Sayfa Nesnesi Modeli (Page Object Model)
Testler büyüdükçe, her testin içine seçici yazmak bakım kâbusuna döner. Sayfa Nesnesi Modeli (Page Object Model, POM — her sayfa/ekran için seçicileri ve eylemleri tek bir sınıfta toplayan tasarım deseni), seçiciyi tek yerde tutar; arayüz değişince tek dosyada güncellersiniz. YZ'ye testleri doğrudan değil, POM yapısında ürettirin; bu bakımı köklü biçimde kolaylaştırır.
Zayıf prompt / Güçlü prompt
Zayıf: "Giriş sayfası için Selenium testi yaz."
Güçlü: "Playwright (TypeScript) ile giriş akışı testi yaz. Seçiciler yalnızca data-testid kullansın; XPath veya CSS sınıfı kullanma. Kör sleep yok; Playwright'ın otomatik/açık beklemelerini kullan. Page Object Model uygula: LoginPage sınıfı. Üç test: (1) doğru bilgiyle giriş ve panele yönlenme, (2) yanlış şifreyle hata mesajı görünmesi, (3) boş alanla gönder butonunun pasif kalması. Her testte gerçek kullanıcı sonucunu doğrulayan assert kullan; sayfa başlığını değil, kullanıcının gördüğü öğeyi kontrol et."
Güçlü prompt; aracı, dili, seçici politikasını, bekleme stratejisini, mimariyi (POM) ve anlamlı assert beklentisini verir.
Test verisi ve ortam bağımsızlığı
Sağlam bir UI testi yalnızca doğru yazılmakla kalmaz, aynı zamanda kendi test verisini kurar ve temizler. YZ'nin ürettiği testler sık sık, ortamda önceden var olduğu varsayılan bir kullanıcıya veya kayda bağlanır ("admin kullanıcısıyla giriş yap"). Bu varsayım, test başka bir ortamda veya başka bir testten sonra çalıştığında çöker (9. ünitedeki sıra bağımlılığı sorunu). Doğrusu, her testin ihtiyaç duyduğu veriyi test başında oluşturması (veya bir API çağrısıyla hazırlaması), sonunda temizlemesidir. YZ'ye "bu testin bağımlı olduğu her veriyi test içinde kur; dışarıdan hazır veri varsayma" talimatını açıkça verin.
Bir başka kritik nokta, gerçek kullanıcı verisiyle UI testi yapmamaktır. Test ortamında üretim veritabanı kopyası kullanılıyorsa, bu kayıtlar gerçek kişilerin verisidir; ekran görüntüleri ve test kayıtları bu veriyi ifşa edebilir. Sentetik (kurgusal) test hesapları kullanın; hem gizliliği korur hem de testleri tekrarlanabilir kılar. Gerçek bir müşteri hesabıyla "sipariş iptal" testi yapmak, hem etik hem operasyonel bir hatadır.
İpucu: UI testlerini olabildiğince az sayıda tutun; asıl doğrulamayı hızlı ve kararlı olan API ve birim testlere bırakın. UI testi pahalı ve kırılgandır — onu yalnızca gerçekten uçtan uca kullanıcı akışını doğrulamak için kullanın (test piramidi mantığı).
Araç karşılaştırması
Özellik
Selenium
Playwright
Cypress
Diller
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
Otomatik bekleme
Hayır (elle)
Evet (güçlü)
Evet
Çoklu tarayıcı
Geniş
Chromium/Firefox/WebKit
Chromium ağırlıklı
Kırılganlık eğilimi
Yüksek (elle bekleme)
Düşük
Düşük
Öğrenme kolaylığı
Orta
Kolay
Kolay
Paralel çalıştırma
Grid gerekir
Yerleşik
Yerleşik/ücretli
YZ'den kod isterken hangi araca ait olduğunu net belirtin; aksi hâlde karışık, çalışmayan kod üretebilir.
Dört kopyalanabilir şablon
1) Sağlam UI testi üretimi:
Rolün: kıdemli test otomasyon mühendisi.[Araç + dil] ile şu akış için test yaz: [akış].Kurallar:- Seçiciler yalnızca data-testid; XPath/CSS-sınıfı kullanma.- Kör sleep yok; açık/otomatik bekleme kullan.- Page Object Model uygula.- Her assert gerçek kullanıcı sonucunu doğrulasın.Her testin başına hangi kabul kriterini doğruladığını yorumla.
2) Kırılganlık denetimi:
Aşağıdaki UI testini kırılganlık açısından incele:- Kararsız seçici var mı (uzun XPath, CSS sınıfı)?- Kör sleep/sabit bekleme var mı?- Assert gerçek sonucu mu yoksa önemsiz bir şeyi mi doğruluyor?- Zamanlamaya bağlı yarış (race) riski var mı?Her sorun için düzeltilmiş satırı öner.Test: [testi yapıştır]
3) Page Object'e dönüştürme:
Aşağıdaki düz test kodunu Page Object Model yapısına çevir.Seçicileri ve eylemleri sayfa sınıflarına taşı; test dosyasıyalnızca senaryo akışını okusun. [Araç/dil].Kod: [kodu yapıştır]
4) Sahte-geçiş kanıtı:
Bu UI testinin gerçekten doğrulama yaptığını kanıtla:Uygulama kodunda hangi tek değişikliği yaparsam bu testKIRMIZIYA döner? Eğer testi kıracak bir değişiklik bulamıyorsan,bu test yetersizdir; eksik assert'leri ekle.Test: [testi yapıştır]
Üç mini vaka
Vaka 1 — Kırılgan seçiciden kurtuluş. Bir ekibin YZ ile ürettiği 40 testin %70'i, arayüz güncellemesinden sonra kırıldı; hiçbiri gerçek hata değildi, hepsi kırılgan XPath seçicileriydi. Ekip "kırılganlık denetimi" şablonuyla testleri data-testid tabanına çevirdi. Sonraki üç arayüz güncellemesinde yanlış kırılma sayısı sıfıra indi; bakım süresi haftada 6 saatten 30 dakikaya düştü.
Vaka 2 — Sahte-geçen UI testi. YZ, bir "sepete ekle" testi üretti; test yeşildi. "Sahte-geçiş kanıtı" şablonu çalıştırıldığında, testin yalnızca butona tıklayıp sayfa başlığını kontrol ettiği, sepet sayacının artıp artmadığını hiç doğrulamadığı görüldü. Sepet mantığı tamamen bozulsa bile test geçiyordu. Gerçek assert (sepet rozetinin "1" olması) eklendi.
Vaka 3 — Kör bekleme tuzağı. YZ'nin ürettiği Selenium testinde her adımdan sonra sleep(2) vardı; 60 test 14 dakika sürüyor ve yine de ara sıra kırılıyordu. Açık beklemeye (elementin tıklanabilir olmasını bekle) çevrildikten sonra süre 5 dakikaya indi ve kırılganlık kayboldu. Kör bekleme hem yavaş hem güvenilmezdi.
Sık yapılan hatalar
- Kırılgan seçicilere razı olmak. YZ'nin ürettiği uzun XPath'leri olduğu gibi kullanmak; ilk arayüz değişikliğinde testler çöker.
- Kör `sleep` bırakmak. Zamanlamayı sabit beklemeyle "çözmek"; hem yavaş hem kararsız.
- Önemsiz assert. Sadece sayfanın yüklendiğini doğrulamak; asıl kullanıcı sonucunu kontrol etmemek (sahte-geçiş).
- POM'suz büyümek. Seçicileri her teste dağıtmak; arayüz değişince onlarca dosyayı elle güncellemek.
- Aracı belirtmemek. YZ'ye hangi araç/dil istediğinizi söylememek; karışık, çalışmayan kod almak.
- Üretilen kodu çalıştırıp geçince güvenmek. Kodu bozarak sınamamak.
Özetle
UI test otomasyonu, gerçek tarayıcıyı programla sürerek kullanıcı davranışını doğrular. YZ bu kodu hızla üretir ama iki büyük tuzak vardır: kırılgan testler (kötü seçici, kör bekleme) ve sahte-geçen testler (eksik/önemsiz assert). Sağlam UI testinin üç direği kararlı seçici (data-testid), açık bekleme ve gerçek kullanıcı sonucunu doğrulayan assert'tir. Testleri Page Object Model'de ürettirmek bakımı köklü biçimde kolaylaştırır. Her üretilen testi "hangi değişiklik bunu kırar" sorusuyla sınayın.
Uygulama görevi
Kendi projenizden bir kullanıcı akışı seçin (örn. giriş veya arama). YZ'ye "sağlam UI testi üretimi" şablonuyla test yazdırın. Sonra: (1) "kırılganlık denetimi" ile seçici ve beklemeleri kontrol edip düzeltin, (2) "sahte-geçiş kanıtı" ile her testin gerçekten doğrulama yaptığını kanıtlayın, (3) kodu bozarak testin kırmızıya döndüğünü gözlemleyin. Üretilen ve düzeltilmiş test sayılarını, bulduğunuz kırılganlık ve sahte-geçiş sayısını raporlayın.
Kontrol listesi
- [ ] YZ'ye araç, dil, seçici politikası ve mimariyi (POM) net verdim.
- [ ] Seçicilerin kararlı (data-testid) olduğunu doğruladım.
- [ ] Kör sleep yerine açık/otomatik bekleme kullanıldığından emin oldum.
- [ ] Her assert'in gerçek kullanıcı sonucunu doğruladığını kontrol ettim.
- [ ] Her testi kodu bozarak sınadım; kırmızıya döndüğünü gördüm.
- [ ] Testleri Page Object Model yapısında topladım.