H6 · JUnit 5/TestNG entegrasyonu + CI: REST Assured yalnızca bir HTTP İSTEMCİSİDİR — request'i kim ÇALIŞTIRACAK, kim RAPORLAYACAK sorusunun cevabı JUnit 5 veya TestNG'dir.
REST Assured yalnızca bir HTTP İSTEMCİSİDİR — request'i kim ÇALIŞTIRACAK, kim RAPORLAYACAK sorusunun cevabı JUnit 5 veya TestNG'dir. Bu, G6'da gördüğün Newman'ın rolüyle AYNIDIR: Newman bir Postman koleksiyonunu ÇALIŞTIRIR/RAPORLAR, JUnit/TestNG ise bir REST Assured test SINIFINI çalıştırır/raporlar. `mvn test` (veya `mvn verify`) bu testleri komut satırından/CI'da tetikler — GRUP B'de yazdığın uygulama koduyla AYNI Maven projesinde yaşarlar. Peki bu neden önemli — testler ayrı bir proje olamaz mıydı? Çünkü aynı projede yaşamak, kod DEĞİŞTİĞİNDE testin AYNI `mvn install`/CI adımında OTOMATİK çalışmasını garanti eder; ayrı bir proje olsaydı, "testleri de çalıştırmayı unutma" riski (G4'teki gibi) geri dönerdi. **Derin JUnit/TestNG+CI kurulumu için → `/rest-assured` sayfasına bak.**
🎬 REST Assured'un Newman Karşılığı
REST Assured: sadece istemci
JUnit/TestNG çalıştırır
REST Assured tek başına sadece bir request gönderme aracıdır — onu KİM çalıştıracak?
JUnit 5/TestNG, `@Test` metotlarını bulup ÇALIŞTIRIR ve sonucu RAPORLAR — G6'daki Newman'ın REST Assured karşılığı.
`mvn test` bunu CI'a bağlar — GRUP B kodunun bulunduğu AYNI projede, her push'ta OTOMATİK çalışır.
REST Assured Testini CI'a Bağlama Sırası
JUnit/TestNG ile yaz…
@Test annotation'ı ile REST Assured kodunu bir test metoduna sar.
mvn test ile doğrula…
Yerelde mvn test çalıştırıp testin geçtiğini doğrula.
Uygulamayı başlatan adımdan SONRA mvn test'i workflow'a ekle.