Örnek sorular
Ta Synchronization Flaky TestsZorluk 1
Selenium WebDriver'da implicit wait ile explicit wait arasındaki temel pratik fark nedir?
- aImplicit wait yalnızca CSS seçicilerle, explicit wait yalnızca XPath ile çalışır
- bImplicit wait tüm aramalar için tek bir global timeout ayarlar; explicit wait tek bir elemandaki adlandırılmış tek bir koşulu bekler✓
- cExplicit wait tüm test paketini duraklatır, implicit wait yalnızca mevcut test metodunu duraklatır
- dImplicit wait her eleman örneği için ayrı ayrı yapılandırılır, explicit wait ise tüm driver oturumu için tek seferde yapılandırılır
Açıklama:Implicit wait (driver.manage().timeouts().implicitlyWait(...)) driver'ın her findElement çağrısına uyguladığı global bir polling timeout'udur; explicit wait ise (WebDriverWait + ExpectedConditions) devam etmeden önce tek, belirli bir elemandaki belirli, adlandırılmış bir koşulu bekler.
Ta Synchronization Flaky TestsZorluk 1
Test otomasyonu bağlamında "flaky test" (kararsız test) nedir?
- aTest edilen kod değişmediği halde ara sıra geçen ara sıra kalan bir test✓
- bKapsadığı özellik kaldırıldığı için her zaman başarısız olan bir test
- cEkibin üzerinde anlaştığı performans bütçesinden daha yavaş çalışan bir test
- dStatik olarak derlenen bir dil yerine yorumlanan bir script dilinde yazılmış bir test
Açıklama:Kararsız (flaky) bir test, aynı kod üzerinde aralıklı olarak geçer ve kalır; bu genellikle gerçek bir hatadan değil, zamanlama, ortam ya da test izolasyonu sorunlarından kaynaklanır ve pakete duyulan güveni zedeler.
Ta Synchronization Flaky TestsZorluk 1
Aynı Selenium WebDriver script'inde implicit ve explicit wait'i karıştırmak neden genellikle önerilmez?
- aİkisi aynı anda yapılandırıldığında Selenium derleme zamanı hatası verir
- bExplicit wait, oturumun geri kalanında implicit wait'i sessizce devre dışı bırakır
- cTimeout'ları öngörülemez biçimde birleşerek bazı çağrıların çok daha uzun beklemesine yol açabilir✓
- dImplicit wait, ancak script içinde herhangi bir yerde tanımlanan her explicit wait çoktan tamamlandıktan sonra devreye girer
Açıklama:İki mekanizma aynı anda etkili olabildiğinden, bir explicit wait'in polling döngüsü içindeki bir findElement çağrısı implicit wait timeout'una da tabi olabilir; bu da ikisinin üst üste binerek beklenmedik derecede uzun veya tutarsız beklemelere yol açmasına neden olur.
Ta Synchronization Flaky TestsZorluk 1
Selenium'da (Java binding) hangi satır, bir elemana tıklamadan önce onun tıklanabilir hale gelmesini en fazla 10 saniye bekleyerek doğru şekilde bekler?
- adriver.findElement(By.id("submit")).waitUntilClickable(10).click();
- btry { Thread.sleep(10000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } driver.findElement(By.id("submit")).click();
- cdriver.manage().timeouts().pageLoadTimeout(10, TimeUnit.SECONDS);
- dnew WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(By.id("submit"))).click();✓
Açıklama:WebDriverWait ile ExpectedConditions.elementToBeClickable birlikte kullanıldığında, bulunan eleman hem görünür hem etkin olana kadar polling yapılır ve ardından .click() zincirlenebilir şekilde eleman döndürülür; diğer seçenekler ya var olmayan bir metot kullanır, ya sabit bir sleep içerir ya da alakasız bir sayfa-yükleme timeout'u yapılandırır.
Ta Synchronization Flaky TestsZorluk 1
Bir UI testindeki bir zamanlama sorununu çözmek için sabit bir sleep (ör. Thread.sleep(5000)) kullanmanın genel olarak en büyük sorunu nedir?
- aSayfa hızlıysa zaman kaybettirir, beklenenden yavaşsa yine de başarısız olur✓
- bHiçbir modern otomasyon framework'ü tarafından desteklenmez
- cAssertion çalışmadan önce tarayıcının kapanmasına neden olur
- dYalnızca Cypress ile çalışır, Selenium ile asla çalışmaz
Açıklama:Sabit bir sleep bir süre tahmin eder: gerçek bekleme daha kısaysa test gereksiz yere yavaş çalışır; gerçek bekleme bazen daha uzunsa (yavaş ağ, animasyon, sunucu yükü) test yine de başarısız olur; bu yüzden koşul-tabanlı explicit wait'ler tercih edilir.
Ta Synchronization Flaky TestsZorluk 2
Cypress'in yerleşik "retry-ability" (tekrar deneme) mekanizması, cy.get('.item').should('be.visible') gibi bir komutu nasıl ele alır?
- aKomutu tam olarak bir kez çalıştırır ve mevcut DOM durumuna göre anında geçti/kaldı raporlar
- bGeliştiricinin komutu JavaScript ile yazılmış özel bir retry döngüsüne manuel olarak sarmasını gerektirir
- cDOM'u yeniden sorgular ve assertion geçene ya da timeout dolana kadar tekrar tekrar kontrol eder✓
- dTüm test çalışmasını duraklatır ve bir insanın elemanın görünür olduğunu onaylamasını bekler
Açıklama:Cypress komutları ve .should() gibi assertion'lar, yapılandırılabilir bir timeout içinde (çoğu komut için varsayılan 4sn) assertion geçene ya da süre dolana kadar mevcut DOM durumuna karşı otomatik olarak yeniden denenir; Cypress testlerini explicit wait olmadan zamanlamaya dayanıklı yapan şey budur.