🏗️ Framework Mimarisi (SOLID + POM)

Framework Mimarisi (SOLID + POM): Bu sekmeye kadar öğrendiğin her parça (given/when/then, POJO, auth, JSON path, test zinciri) tek başına çalışıyor ama HENÜZ bir mimariye bağlanm

Bu sekmeye kadar öğrendiğin her parça (given/when/then, POJO, auth, JSON path, test zinciri) tek başına çalışıyor ama HENÜZ bir mimariye bağlanmadı — dosyanın en başındaki `raBaseTestStep`'te gördüğün "@BeforeAll static RequestSpecification spec" deseni tam olarak bu sekmenin temelidir, şimdi onu tüm katmanlarıyla inşa ediyoruz. RequestSpecBuilder, bir matbaanın antetli kağıt şablonudur: her belge (her istek) aynı logoyu/adresi (baseURI, ortak header'lar, filtreler) yeniden çizmez, TEK bir şablonu kullanır. İkinci benzetme: Selenium'daki DriverManager/WaitFactory ile karşılaştır — orada "hangi thread hangi driver'ı alır" sorunu vardı, burada öyle bir sorun YOK çünkü HTTP isteği state'siz (stateless) bir çağrıdır, paylaşılacak olan tarayıcı oturumu değil sadece İSTEK YAPILANDIRMASIdır (baseURI, content-type, filtreler). Peki given().baseUri(...).header(...) zaten her testte yazılabiliyorken, neden RequestSpecBuilder'a ihtiyaç var — dört-beş satırı kopyalamak yetmez mi? Yeter, ama SADECE bir test sınıfı için; 30 test sınıfının HER birinde bu satırları tekrar yazarsan, ortam değiştiğinde (staging→prod baseURI) 30 dosya elle taranır. Java karşılaştırması: bu, Spring'te paylaşılan bir `RestTemplate`/`WebClient` bean'i kurmakla AYNI motivasyon — pahalı/tekrar eden yapılandırmayı merkezileştir. QA bağlamı: RequestSpecBuilder olmadan 30 test sınıfı varken API'ye yeni bir zorunlu header eklenirse (örn. `X-API-Version`) 30 dosya kırılır; merkezi bir spec'te bu TEK satırlık bir değişikliktir.

REST Assured Framework'ünü Adım Adım İnşa Et

Aşağıdaki 4 parça, bu sekmede birazdan tek tek inşa edeceğin mimarinin BÜYÜK RESMİ. Şimdilik hepsi kilitli — her parçanın kendi adımındaki "Kendin Dene" pratiğini ilk kez doğru bitirdiğinde, o parça burada kilitliden İNŞA EDİLDİ'ye döner.

Core / RequestSpec Katmanı

"POM" Yerine Service Object

🧭 Adım 1 — Büyük Resim: RequestSpec Zinciri Mindmap

Aynı mimari burada beş ayrı açıdan gösteriliyor: önce ana akış (bir test çağrıldığında istek nasıl kurulur), sonra kurulum akışı (pom.xml'den BaseTest'e, oradan test sınıfına), sonra "paralel çalışma" (JUnit5'te static spec'in sınıf seviyesindeki izolasyonu Selenium'un ThreadLocal'ından NEDEN farklıdır), sonra veri paylaşım kapsamı (static/instance/parametre scope'u) ve son olarak her sınıfın "yapar/yapmaz" listesi.

3️⃣ Paralel Çalışma — static spec, Selenium'un ThreadLocal'ından NEDEN Farklı?

Sınıf Seviyesi İzolasyon

JUnit5 Paralel Sınıflar

Selenium'da ThreadLocal'a ihtiyaç vardı çünkü paylaşılan şey bir WebDriver OTURUMUYDU — aynı process içindeki farklı thread'ler aynı tarayıcıyı KARIŞTIRMASIN diye izolasyon gerekiyordu. REST Assured'da paylaşılan şey ise bir RequestSpecification YAPILANDIRMASIdır — HTTP isteği doğası gereği stateless olduğu için, aynı spec'i aynı anda 10 farklı test metodu KULLANSA bile birbirine karışmaz (her `given().spec(spec)` çağrısı kendi bağımsız isteğini oluşturur). Bu yüzden framework mimarin AÇISINDAN önemli olan şey ThreadLocal değil, static alanın SINIF seviyesinde doğru kurulmasıdır (her sınıf kendi @BeforeAll'unda spec'ini kendi kurar).

4️⃣ Veri Paylaşım Kapsamı — Neyin Ömrü Ne Kadar?

static (sınıf seviyesi)

instance (metot seviyesi)