{"id":32112,"date":"2025-10-17T22:01:50","date_gmt":"2025-10-17T19:01:50","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/xpathy-flaky-testleri-bitiren-fluent-api\/"},"modified":"2025-10-17T22:01:50","modified_gmt":"2025-10-17T19:01:50","slug":"xpathy-flaky-testleri-bitiren-fluent-api","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/xpathy-flaky-testleri-bitiren-fluent-api\/","title":{"rendered":"XPathy: Flaky Testleri Bitiren Fluent API"},"content":{"rendered":"

<\/p>\n

Web otomasyon testleriniz s\u00fcrekli “flaky” mi oluyor? Dinamik web sayfalar\u0131nda elementleri bulmak kabusunuz mu? Geleneksel XPath’in bak\u0131m\u0131 zor, k\u0131r\u0131lgan yap\u0131s\u0131na bir alternatif ar\u0131yorsan\u0131z, XPathy’nin Fluent API’\u0131 ile tan\u0131\u015f\u0131n. Bu makale, testlerinizi nas\u0131l daha sa\u011flam, okunabilir ve s\u00fcrd\u00fcr\u00fclebilir hale getirece\u011finizi ad\u0131m ad\u0131m a\u00e7\u0131kl\u0131yor.<\/p>\n

Modern web uygulamalar\u0131, s\u00fcrekli de\u011fi\u015fen ve geli\u015fen yap\u0131lar\u0131yla test otomasyon m\u00fchendisleri i\u00e7in ciddi zorluklar sunar. Tek sayfa uygulamalar\u0131 (SPA’lar) ve dinamik olarak y\u00fcklenen i\u00e7erikler, elementlerin DOM’daki konumunu s\u00fcrekli de\u011fi\u015ftirebilir veya g\u00f6r\u00fcn\u00fcrl\u00fcklerini anl\u0131k olarak etkileyebilir. Bu durum, otomasyon testlerimizin en b\u00fcy\u00fck d\u00fc\u015fman\u0131 olan “flaky test” olgusunu ortaya \u00e7\u0131kar\u0131r. Flaky testler, ayn\u0131 kod ve ayn\u0131 ortamda bazen ge\u00e7erken bazen ba\u015far\u0131s\u0131z olan, g\u00fcvenilmez testlerdir. Bir testin bir kez ba\u015far\u0131l\u0131 olup, sonraki \u00e7al\u0131\u015ft\u0131rmada rastgele bir nedenden ba\u015far\u0131s\u0131z olmas\u0131, otomasyon sistemlerine duyulan g\u00fcveni temelden sarsar.<\/p>\n

Geleneksel olarak, web elementlerini hedeflemek i\u00e7in XPath ve CSS Selector’lar kullan\u0131l\u0131r. XPath, esnekli\u011fi sayesinde \u00e7o\u011fu senaryoda i\u015fimizi g\u00f6rse de, karma\u015f\u0131k ve dinamik web sayfalar\u0131nda yaz\u0131m\u0131 zorla\u015f\u0131r, okunabilirli\u011fi d\u00fc\u015fer ve en \u00f6nemlisi son derece k\u0131r\u0131lgan hale gelir. K\u00fc\u00e7\u00fck bir UI de\u011fi\u015fikli\u011fi, hatta bir div etiketinin araya girmesi bile t\u00fcm XPath ifadesini ge\u00e7ersiz k\u0131labilir. Bu durum, test senaryolar\u0131n\u0131n s\u00fcrekli bak\u0131m\u0131n\u0131 gerektirir ve geli\u015ftirme s\u00fcre\u00e7lerini yava\u015flat\u0131r.<\/p>\n

Peki, bu k\u0131r\u0131lganl\u0131\u011f\u0131 nas\u0131l a\u015fabiliriz? Test otomasyonunun temel amac\u0131, yaz\u0131l\u0131m\u0131n kalitesini g\u00fcvence alt\u0131na almak ve geli\u015ftirme s\u00fcrecini h\u0131zland\u0131rmakt\u0131r. Ancak, flaky testler bu hedeflerin tam tersini yapar; geli\u015ftiricilerin zaman\u0131n\u0131 hata ay\u0131klama ve s\u00fcrekli test d\u00fczeltmeleriyle bo\u015fa harcamalar\u0131na neden olur. G\u00fcvenilir olmayan test sonu\u00e7lar\u0131, ger\u00e7ek hatalar\u0131n g\u00f6zden ka\u00e7mas\u0131na veya gereksiz yere d\u00fczeltmeler yap\u0131lmas\u0131na yol a\u00e7abilir. Bu d\u00f6ng\u00fc, sonunda otomasyon \u00e7abalar\u0131na olan inanc\u0131 azalt\u0131r ve manuel testlere geri d\u00f6n\u00fc\u015f e\u011filimini tetikler. \u0130\u015fte tam da bu noktada, geleneksel XPath yakla\u015f\u0131mlar\u0131n\u0131n yetersiz kald\u0131\u011f\u0131 ve daha modern, daha sa\u011flam \u00e7\u00f6z\u00fcmlere ihtiya\u00e7 duyuldu\u011fu a\u00e7\u0131k\u00e7a ortaya \u00e7\u0131kar. Art\u0131k sadece elementleri bulmak yeterli de\u011fil; onlar\u0131 dinamik ortamlara adapte olabilen, kolayca okunabilen ve bak\u0131m\u0131 yap\u0131labilir bir \u015fekilde bulmam\u0131z gerekiyor. Bu ihtiya\u00e7, XPathy gibi Fluent API’lar\u0131n y\u00fckseli\u015fini tetikleyen ana fakt\u00f6rlerden biridir. Bu t\u00fcr ara\u00e7lar, testlerin yaz\u0131lma ve s\u00fcrd\u00fcr\u00fclme \u015feklini k\u00f6kten de\u011fi\u015ftirerek, geli\u015ftiricilere daha sa\u011flam ve g\u00fcvenilir otomasyon testleri olu\u015fturma g\u00fcc\u00fc verir.<\/p>\n

Raw XPath Neden “\u00d6ld\u00fc”? Geleneksel Yakla\u015f\u0131m\u0131n Eksiklikleri Nelerdi?<\/h2>\n

Geleneksel XPath, web elementlerini DOM (Belge Nesne Modeli) a\u011fac\u0131ndaki konumlar\u0131na g\u00f6re hedeflemek i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Ancak bu g\u00fcc\u00fcn beraberinde getirdi\u011fi baz\u0131 ciddi zay\u0131fl\u0131klar vard\u0131r. Bir elementin tam yolunu belirten mutlak XPath’ler (\/html\/body\/div[1]\/section\/ul\/li[2]\/a<\/code> gibi) son derece k\u0131r\u0131lgan olmalar\u0131yla bilinirler. Sayfaya k\u00fc\u00e7\u00fck bir element eklenmesi veya \u00e7\u0131kar\u0131lmas\u0131 bile bu yolu ge\u00e7ersiz k\u0131labilir. G\u00f6receli XPath’ler (\/\/div[@id='sidebar']\/a[contains(text(),'Hizmetlerimiz')]<\/code> gibi) biraz daha esnek olsa da, yine de b\u00fcy\u00fck bir bak\u0131m y\u00fck\u00fc olu\u015ftururlar.<\/p>\n

D\u00fc\u015f\u00fcn\u00fcn ki, bir e-ticaret sitesindeki bir \u00fcr\u00fcn kart\u0131n\u0131 hedeflemek istiyorsunuz. Geleneksel bir XPath \u015f\u00f6yle g\u00f6r\u00fcnebilir:<\/p>\n

\n    \/\/div[@class='product-list']\/div[3]\/div[@class='product-card']\/a[@data-product-id='12345']\/h3\n  <\/pre>\n
<\/code><\/p>\n
Bu ifade, \u00fc\u00e7\u00fcnc\u00fc \u00fcr\u00fcn\u00fc se\u00e7en, belirli bir ID'ye sahip \u00fcr\u00fcn kart\u0131n\u0131n i\u00e7indeki ba\u015fl\u0131\u011f\u0131 hedefliyor. E\u011fer \u00fc\u00e7\u00fcnc\u00fc s\u0131radaki \u00fcr\u00fcn\u00fcn yeri de\u011fi\u015firse veya araya yeni bir element girerse, bu XPath an\u0131nda bozulur. Ayr\u0131ca, bu ifadeyi okumak ve neyi hedefledi\u011fini anlamak i\u00e7in HTML yap\u0131s\u0131n\u0131 iyi bilmek gerekir. \u00d6zellikle karma\u015f\u0131k XPath'ler, okunabilirlik a\u00e7\u0131s\u0131ndan bir labirente d\u00f6n\u00fc\u015febilir.<\/p>\n
\n
Geleneksel XPath'in bu karma\u015f\u0131k yap\u0131s\u0131, test otomasyonu ekipleri i\u00e7in zamanla ciddi bir maliyet olu\u015fturur. Testler ba\u015far\u0131s\u0131z oldu\u011funda, \u00f6ncelikle XPath ifadelerinin kontrol edilmesi gerekir ki bu da ciddi bir zaman kayb\u0131d\u0131r.<\/p>\n<\/p><\/div>\n
Bir di\u011fer \u00f6nemli sorun, dinamik web siteleridir. JavaScript ile s\u00fcrekli g\u00fcncellenen veya tamamen yeniden \u00e7izilen sayfalar, elementlerin ID'lerini, class'lar\u0131n\u0131 veya di\u011fer niteliklerini de\u011fi\u015ftirebilir. \u00d6rne\u011fin, bir form g\u00f6nderimi sonras\u0131 dinamik olarak olu\u015fturulan bir ba\u015far\u0131 mesaj\u0131n\u0131 hedeflemek, bazen imkans\u0131z hale gelebilir \u00e7\u00fcnk\u00fc mesaj\u0131n tam XPath'i her zaman farkl\u0131 olabilir veya sadece belirli bir zaman diliminde var olabilir. Geleneksel XPath, bu t\u00fcr dinamik de\u011fi\u015fimlere kar\u015f\u0131 \u00e7ok diren\u00e7li de\u011fildir. starts-with()<\/code> veya contains()<\/code> gibi fonksiyonlarla bir nebze esneklik sa\u011flansa da, genel \u00e7\u00f6z\u00fcm sunmaktan uzakt\u0131r.<\/p>\n
Ayr\u0131ca, geleneksel XPath'in en b\u00fcy\u00fck handikaplar\u0131ndan biri de \"insan odakl\u0131\" olmamas\u0131d\u0131r. Bir geli\u015ftirici veya test m\u00fchendisi, bir UI elementini d\u00fc\u015f\u00fcn\u00fcrken \"Sayfadaki 'Kaydet' d\u00fc\u011fmesini bul\" veya \"\u00dcr\u00fcn listesindeki 'Sepete Ekle' yazan butonu bul\" gibi ifadelerle d\u00fc\u015f\u00fcn\u00fcr. Ancak, geleneksel XPath yazarken bu do\u011fal d\u00fc\u015f\u00fcnce tarz\u0131ndan uzakla\u015farak, elementin DOM i\u00e7indeki hiyerar\u015fik ve teknik konumuna odaklanmak zorunda kal\u0131r\u0131z. Bu da d\u00fc\u015f\u00fcnce yap\u0131s\u0131yla kodlama aras\u0131ndaki mesafeyi a\u00e7ar ve hataya a\u00e7\u0131k bir ortam yarat\u0131r. Bu nedenlerle, test otomasyonunun giderek daha \u00f6nemli hale geldi\u011fi modern geli\u015ftirme d\u00f6ng\u00fclerinde, \"Raw XPath\" yakla\u015f\u0131m\u0131 art\u0131k yetersiz kalmakta ve \"\u00f6l\u00fc\" olarak nitelendirilmektedir. Daha sezgisel, daha sa\u011flam ve daha bak\u0131m\u0131 kolay bir yakla\u015f\u0131ma ihtiya\u00e7 duyulmaktad\u0131r.<\/p>\n
XPathy Nedir ve Fluent API Ne Anlama Gelir?<\/h2>\n
XPathy, web otomasyon testlerinizdeki element bulma s\u00fcrecini devrim niteli\u011finde de\u011fi\u015ftirmeyi hedefleyen, XPath ifadeleri olu\u015fturmak i\u00e7in tasarlanm\u0131\u015f bir Fluent API yakla\u015f\u0131m\u0131d\u0131r. \"Fluent API\", bir API tasar\u0131m desenidir ve zincirleme metot \u00e7a\u011fr\u0131lar\u0131 kullanarak kodun daha okunabilir ve do\u011fal bir dil gibi akmas\u0131n\u0131 sa\u011flar. Ama\u00e7, karma\u015f\u0131k i\u015flemleri bile ad\u0131m ad\u0131m, anla\u015f\u0131l\u0131r bir s\u0131rayla ifade etmektir. XPathy'nin temel felsefesi, karma\u015f\u0131k ve k\u0131r\u0131lgan XPath ifadelerini, insan diline yak\u0131n, anla\u015f\u0131l\u0131r ve s\u00fcrd\u00fcr\u00fclebilir bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fcrmektir.<\/p>\n
Geleneksel XPath yazarken kar\u015f\u0131la\u015f\u0131lan zorluklar g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, XPathy'nin Fluent API'\u0131, element hedefleme s\u00fcrecini basit, anla\u015f\u0131l\u0131r ad\u0131mlara b\u00f6ler. \u00d6rne\u011fin, bir \"Kaydet\" butonunu bulmak i\u00e7in art\u0131k \/\/button[text()='Kaydet']<\/code> gibi bir ifade yazmak yerine, XPathy ile XPathy().button().with_text(\"Kaydet\")<\/code> \u015feklinde ifade edersiniz. Bu, sadece bir s\u00f6z dizimi de\u011fi\u015fikli\u011fi de\u011fil, ayn\u0131 zamanda elementin ne oldu\u011funu ve neden se\u00e7ildi\u011fini anlatan bir ifade bi\u00e7imidir. Kodun okuyucusu, elementin hangi \u00f6zelliklere sahip oldu\u011funu ve ne anlama geldi\u011fini kolayca kavrayabilir, bu da bak\u0131m maliyetlerini \u00f6nemli \u00f6l\u00e7\u00fcde d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n
\n
Uzman \u0130pucu:<\/strong> Fluent API, kodunuzu do\u011fal dil gibi okuman\u0131z\u0131 sa\u011flayarak karma\u015f\u0131kl\u0131\u011f\u0131 azalt\u0131r ve hatalar\u0131 daha kolay tespit etmenize olanak tan\u0131r.<\/p>\n<\/p><\/div>\n
XPathy'nin Fluent API'\u0131, bir dizi metodu birbirine zincirleyerek karma\u015f\u0131k XPath'leri olu\u015fturur. Bu metotlar, HTML elementinin etiket ad\u0131 (div()<\/code>, button()<\/code>, input()<\/code> gibi), i\u00e7erdi\u011fi metin (with_text()<\/code>, contains_text()<\/code> gibi), sahip oldu\u011fu nitelikler (with_id()<\/code>, with_class()<\/code>, has_attribute()<\/code> gibi) veya DOM i\u00e7indeki ili\u015fkileri (parent()<\/code>, has_child()<\/code> gibi) baz alabilir. Bu yakla\u015f\u0131m, XPath ifadelerini daha mod\u00fcler hale getirir. Her bir metot, belirli bir ko\u015fulu veya \u00f6zelli\u011fi temsil eder ve bir araya geldiklerinde g\u00fc\u00e7l\u00fc ve spesifik bir element se\u00e7ici olu\u015ftururlar.<\/p>\n
S\u00fcrd\u00fcr\u00fclebilirlik a\u00e7\u0131s\u0131ndan da XPathy \u00f6nemli avantajlar sunar. Bir UI de\u011fi\u015fikli\u011fi oldu\u011funda, geleneksel XPath'i ba\u015ftan sona yeniden yazmak yerine, XPathy ifadesindeki ilgili metot \u00e7a\u011fr\u0131s\u0131n\u0131 g\u00fcncellemek genellikle yeterlidir. \u00d6rne\u011fin, bir elementin metni de\u011fi\u015firse sadece with_text()<\/code> metodundaki de\u011feri g\u00fcncellemek yeterli olurken, DOM yap\u0131s\u0131ndaki bir de\u011fi\u015fiklik sadece div()<\/code> yerine span()<\/code> gibi etiket ad\u0131n\u0131 de\u011fi\u015ftirmeyi gerektirebilir. Bu mod\u00fcler yap\u0131, testlerin bak\u0131m\u0131n\u0131 h\u0131zland\u0131r\u0131r ve hatal\u0131 XPath'lerin neden oldu\u011fu \"flaky test\" say\u0131s\u0131n\u0131 azalt\u0131r. Sonu\u00e7 olarak, XPathy, test otomasyonunu sadece daha kolay de\u011fil, ayn\u0131 zamanda daha g\u00fcvenilir ve verimli hale getiren bir yakla\u015f\u0131md\u0131r.<\/p>\n
XPathy'nin Temel Prensipleri ve Felsefesi Nelerdir?<\/h3>\n
XPathy'nin arkas\u0131nda yatan temel prensipler, modern test otomasyonunun ihtiya\u00e7lar\u0131na cevap vermek ve geleneksel XPath'in zay\u0131fl\u0131klar\u0131n\u0131 gidermek \u00fczerine kuruludur. Bu prensipler, geli\u015ftiricilere daha iyi, daha sa\u011flam ve daha keyifli bir test yazma deneyimi sunmay\u0131 hedefler:<\/p>\n
    \n
  • Okunabilirlik (Readability):<\/strong> En \u00f6nemli prensiplerden biridir. XPathy, kodun do\u011fal bir dil gibi okunmas\u0131n\u0131 sa\u011flar. XPathy().div().with_text(\"Kullan\u0131c\u0131 Ad\u0131\")<\/code> ifadesi, \"\u0130\u00e7erisinde 'Kullan\u0131c\u0131 Ad\u0131' metni olan bir div bul\" anlam\u0131na gelir ve bir test m\u00fchendisi veya geli\u015ftiricinin anadilinde d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fc \u015fekle \u00e7ok yak\u0131nd\u0131r. Bu sayede, kodun ne yapt\u0131\u011f\u0131n\u0131 anlamak i\u00e7in DOM yap\u0131s\u0131n\u0131 detayl\u0131ca incelemeye gerek kalmaz.<\/li>\n
  • S\u00fcrd\u00fcr\u00fclebilirlik (Maintainability):<\/strong> Web uygulamalar\u0131 s\u00fcrekli de\u011fi\u015fir. XPathy, bu de\u011fi\u015fikliklere kar\u015f\u0131 daha diren\u00e7li ifadeler olu\u015fturmaya odaklan\u0131r. Bir UI de\u011fi\u015fikli\u011fi oldu\u011funda, t\u00fcm XPath'i yeniden yazmak yerine, ilgili metot \u00e7a\u011fr\u0131s\u0131n\u0131 g\u00fcncellemek yeterli olur. Bu, testlerin bak\u0131m s\u00fcresini ve maliyetini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/li>\n
  • Sa\u011flaml\u0131k (Robustness):<\/strong> Dinamik element ID'leri, de\u011fi\u015fen class'lar veya DOM'daki hiyerar\u015fik de\u011fi\u015fiklikler flaky testlere neden olabilir. XPathy, starts_with()<\/code>, contains_text()<\/code>, has_attribute()<\/code> gibi metotlarla bu dinamik de\u011fi\u015fimlere kar\u015f\u0131 daha dayan\u0131kl\u0131 element se\u00e7icileri olu\u015fturmay\u0131 te\u015fvik eder. Bu sayede testler, k\u00fc\u00e7\u00fck UI de\u011fi\u015fikliklerinden daha az etkilenir.<\/li>\n
  • Dinamik \u0130\u00e7eri\u011fe Adaptasyon (Adaptability to Dynamic Content):<\/strong> AJAX \u00e7a\u011fr\u0131lar\u0131 veya JavaScript manip\u00fclasyonlar\u0131 ile y\u00fcklenen i\u00e7erik, elementlerin anl\u0131k olarak var olup olmad\u0131\u011f\u0131n\u0131 etkileyebilir. XPathy, bu t\u00fcr dinamik i\u00e7erikleri hedeflemek i\u00e7in daha esnek y\u00f6ntemler sunar ve testlerin daha g\u00fcvenilir olmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir elementin sadece belirli bir metin i\u00e7erdi\u011fini bilmek yeterliyken, tam metnini bilme zorunlulu\u011funu ortadan kald\u0131r\u0131r.<\/li>\n
  • Mod\u00fclerlik (Modularity):<\/strong> Her bir XPathy metodu, XPath ifadesinin belirli bir par\u00e7as\u0131n\u0131 temsil eder. Bu mod\u00fcler yap\u0131, karma\u015f\u0131k se\u00e7icilerin daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alar halinde in\u015fa edilmesini sa\u011flar. Ayn\u0131 zamanda, belirli element se\u00e7ici desenlerinin yeniden kullan\u0131labilirli\u011fini art\u0131r\u0131r.<\/li>\n<\/ul>\n
    Bu prensipler, XPathy'nin sadece bir ara\u00e7 olmaktan \u00f6te, test otomasyonuna daha stratejik ve verimli bir yakla\u015f\u0131m sunan bir felsefe oldu\u011funu g\u00f6sterir. Geli\u015ftiricilerin \"flaky test\" sendromundan kurtulmalar\u0131na ve ger\u00e7ekten g\u00fcvenilir test otomasyonu olu\u015fturmalar\u0131na yard\u0131mc\u0131 olur.<\/p>\n
    XPathy ile Element Bulma Nas\u0131l Yap\u0131l\u0131r? Ad\u0131m Ad\u0131m Uygulama<\/h2>\n
    XPathy'nin Fluent API'\u0131n\u0131 kullanarak element bulma s\u00fcreci olduk\u00e7a sezgisel ve basittir. Geleneksel XPath'in karma\u015f\u0131kl\u0131\u011f\u0131ndan uzakla\u015farak, kodunuzu daha okunabilir ve y\u00f6netilebilir hale getirebilirsiniz. \u015eimdi, ad\u0131m ad\u0131m XPathy ile nas\u0131l element bulaca\u011f\u0131m\u0131za dair \u00f6rnekler \u00fczerinde duraca\u011f\u0131z. Bu \u00f6rneklerde, Python i\u00e7in hipotetik bir xpathy<\/code> k\u00fct\u00fcphanesi kullan\u0131ld\u0131\u011f\u0131n\u0131 varsayaca\u011f\u0131z, ancak buradaki prensipler \u00e7o\u011fu dilde benzer Fluent API yakla\u015f\u0131mlar\u0131na uyarlanabilir.<\/p>\n
    \u0130lk olarak, en basit senaryo ile ba\u015flayal\u0131m: bir etiket ad\u0131na ve i\u00e7erdi\u011fi metne g\u00f6re element bulma. Diyelim ki, sayfan\u0131zda \"Giri\u015f Yap\" metnine sahip bir d\u00fc\u011fme (