API Mocklama Kullanım Alanları: Ne Zaman ve Neden API Mock'lanmalı

Çoğu ekip bir API'yi nasıl taklit edeceğini bilir. Asıl karar, taklidin ne zaman gerçek bir darboğazı kaldırdığı ve ne zaman bakımı gereken ek bir katmana dönüştüğüdür. Doğru yerde kullanılan mock, geliştirmeyi hızlandırır; alışkanlıkla oluşturulan mock ise gerçeklikten uzaklaşıp testlerinize sessizce yanlış güven verir.

Apidog'u bugün deneyin

Bu yazıyı bir karar kontrol listesi gibi kullanın. Her bölüm, API mock kullanımının pratikte değer ürettiği bir senaryoyu ele alır: tamamlanmamış backend ile frontend geliştirmek, hata yollarını test etmek, üçüncü taraf servisleri izole etmek, demoları deterministik yapmak ve CI testlerini kararlı tutmak.

Paralel ön uç ve arka uç geliştirme

Frontend ekibinin henüz backend tarafından uygulanmamış bir endpoint'e ihtiyacı varsa iki kötü seçenek doğar:

• Frontend bekler.
• Frontend, gerçek servisle ilk temasında bozulabilecek varsayımlarla kod yazar.

Mock burada bağımlılığı keser. Pratik akış şu şekilde olmalıdır:

1. Frontend ve backend ekibi endpoint sözleşmesi üzerinde anlaşır.
2. Sözleşme mümkünse bir OpenAPI dokümanı olarak yazılır.
3. Mock, bu sözleşmeden üretilir.
4. Frontend mock base URL'ine karşı geliştirme yapar.
5. Backend gerçek endpoint'i aynı sözleşmeye göre uygular.
6. Endpoint hazır olduğunda frontend yalnızca base URL'i değiştirir.

Örnek yapı:

Frontend
  API_BASE_URL=https://mock.example.com

Backend hazır olduğunda:
  API_BASE_URL=https://api.example.com

Buradaki kritik nokta, mock'un tek taraflı varsayımlardan değil ortak sözleşmeden üretilmesidir. Sadece frontend'in icat ettiği bir mock, frontend varsayımlarını kodlar. Ortak spesifikasyondan üretilen mock ise iki ekibi hizalı tutar; bu, API sözleşme testinin arkasındaki prensiple aynıdır.

Bu kullanımın pratik getirisi şudur:

• Frontend backend'i beklemeden ekranları geliştirir.
• Backend, yarım endpoint talepleriyle bölünmeden uygulamaya odaklanır.
• Tasarımcılar ve ürün yöneticileri erken aşamada tıklanabilir akış görür.
• Mock, OpenAPI'den üretildiği sürece bakım maliyeti düşük kalır.

İsteğe bağlı olarak tetikleyemeyeceğiniz hata yollarını test etme

Sağlıklı bir API genellikle 200 döner. Ancak istemci kodunuzun yalnızca başarılı yanıtları değil, şu durumları da yönetmesi gerekir:

• 429 Too Many Requests
• 500 Internal Server Error
• 503 Service Unavailable
• zaman aşımı
• bozuk JSON
• alan adı açısından geçersiz ama HTTP açısından başarılı yanıtlar

Gerçek bir sunucu, testiniz istediğinde bu hataları deterministik olarak üretmez. Mock burada kontrol sağlar.

Örneğin bir istemci için şu senaryoları bilinçli şekilde üretin:

Test Edilemeyen Hata	Mock Kurulumu	Neyi Kanıtlar
Sunucu hatası	500 döndür	İstemci yeniden dener, sonra zarifçe düşer
Oran sınırlaması	Retry-After ile 429	İstemci doğru aralığı bekler
Yavaş ağ	Yanıtı 5 sn geciktir	İstemci düzgün bir şekilde zaman aşımına uğrar
Hatalı yük	Bozuk JSON döndür	Ayrıştırıcı çökmeden başarısız olur

Basit bir test mantığı şöyle görünebilir:

it("429 durumunda Retry-After başlığına göre bekler", async () => {
  mockApi.get("/orders").reply(429, {
    error: "rate_limited"
  }, {
    "Retry-After": "3"
  });

  const result = await fetchOrdersWithRetry();

  expect(result.retryAfterSeconds).toBe(3);
});

Bu kullanım çoğu ekipte atlanır. Oysa test edilmemiş hata yönetimi, fiilen sahip olmadığınız hata yönetimidir. Her hata yolunu varsaymak yerine doğrulamak için mock'u kapsamlı API doğrulama testleriyle birlikte kullanın.

Ayrıca yalnızca HTTP hatalarını değil, alan adı açısından hatalı başarılı yanıtları da test edin:

{
  "orderId": "ord_123",
  "status": "UNKNOWN_STATUS",
  "total": -42
}

Bu yanıt teknik olarak 200 olabilir; ancak iş kurallarınız için geçersizdir. Gerçek sunucu doğru çalışıyorsa bunu hiç göndermeyebilir. Mock ile bu tür bozuk ama iyi biçimlendirilmiş verileri üretip istemci varsayımlarını görünür hale getirebilirsiniz.

Üçüncü taraf bir API'nin yerini almak

Testleriniz gerçek bir ödeme işlemcisini, harita servisini veya kargo API'sini çağırıyorsa şu riskleri alırsınız:

• Testler yavaşlar.
• Bazı çağrılar maliyet oluşturabilir.
• Sandbox ortamı kapalıysa testleriniz de kırılır.
• Rate limit veya ağ sorunları, kodunuzla ilgisiz hatalara dönüşür.

Bu durumda üçüncü tarafı mock'layın.

Uygulanabilir akış:

1. Üçüncü taraf API'nin gerçek yanıt örneklerini kaydedin veya yayınlanmış şemasını alın.
2. Bu yanıtlardan mock endpoint'leri oluşturun.
3. Birim ve bileşen testlerini mock'a karşı çalıştırın.
4. Gerçek üçüncü tarafı yalnızca zamanlanmış sözleşme kontrolünde çağırın.

Örnek:

Commit başına test:
  Uygulama -> Mock ödeme API'si

Zamanlanmış sözleşme testi:
  Contract checker -> Gerçek ödeme API'si

Bu yaklaşım testleri hızlı, ücretsiz ve deterministik yapar. Satıcı tarafında kesinti olsa bile commit başına testleriniz çalışmaya devam eder.

Ancak bakım maliyeti vardır. Üçüncü taraf API size haber vermeden değişebilir ve mock bundan haberdar olmaz. Bunu azaltmak için küçük bir zamanlanmış iş çalıştırın:

Her gece:
  1. Gerçek üçüncü taraf endpoint çağrılır.
  2. Yanıt şeması beklenen mock şemasıyla karşılaştırılır.
  3. Sapma varsa ekip uyarılır.

Ayrıca satıcının changelog'una abone olmak da değerlidir. Böylece planlı değişiklikleri başarısız sözleşme testlerinden önce yakalayabilirsiniz.

Demoları ve prototipleri güçlendirme

Müşteri önünde canlı servisleri çağıran demo risklidir. Yavaş sorgu, boş veri seti veya geçici kesinti, iyi hazırlanmış bir sunumu açıklama yapmak zorunda kaldığınız bir duruma çevirebilir.

Mock, demoyu deterministik yapar. Demo için gereken veriyi açıkça kodlarsınız:

• zamanında gönderilen sipariş
• sağlıklı metriklerle dolu dashboard
• temiz sonuç döndüren arama
• başarılı ödeme akışı
• beklenen kullanıcı profili

Örnek demo yanıtı:

{
  "dashboard": {
    "monthlyRevenue": 128000,
    "activeUsers": 4210,
    "conversionRate": 7.4
  }
}

Buradaki amaç test etmek değil, kontrol sağlamaktır. İzleyicinin ne göreceğini siz belirlersiniz ve dış faktörler demoyu bozmaz.

Aynı yaklaşım prototipler için de geçerlidir. Backend henüz yokken UI akışını doğrulayabilirsiniz. Eğer mock, nihai API'nin döndüreceği şekilleri temsil ediyorsa, frontend kodunuz tek kullanımlık iskele olmaktan çıkar; gerçek ürüne taşınabilir hale gelir.

Pratik kontrol listesi:

• Mock yanıtları ürün senaryosunu temsil ediyor mu?
• Endpoint isimleri ve payload yapıları olası gerçek API ile uyumlu mu?
• Frontend'de base URL dışında değişiklik gerekmeyecek mi?
• Demo verisi deterministik mi?

Bu kategorideki araçları karşılaştırmak için çevrimiçi API taklit araçları incelemesine bakabilirsiniz.

CI'ı hızlı ve kararlı tutmak

CI ortamında harici servisleri çağıran test paketi, o servislerin tüm problemlerini miras alır:

• ağ aksaklıkları
• rate limit
• paylaşılan staging verisi
• üçüncü taraf kesintileri
• yavaş yanıt süreleri

Bunların her biri, incelenen kodla ilgisi olmayan flaky test hatalarına dönüşür.

Flaky testler zamanla daha büyük bir soruna yol açar: ekip test hatalarını görmezden gelmeye başlar. Bu da CI'ın amacını boşa çıkarır.

Harici bağımlılıkları mock'lamak, commit başına testleri hermetik hale getirir:

CI test paketi:
  Uygulama -> Mock servisler

Ayrı zamanlanmış iş:
  Sözleşme testleri -> Gerçek servisler

Bu ayrım önemlidir:

• Commit başına testler hızlı ve deterministik kalır.
• Gerçek API ile uyum, ayrı sözleşme testleriyle doğrulanır.
• Mock sapmaları kullanıcılara ulaşmadan yakalanır.

Bu yapı, sağlıklı bir CI/CD test hattı için temel bir ayrımdır.

Hız kazancı yalnızca küçük bir kolaylık değildir. On iki dakikadan doksan saniyeye düşen test paketi, ekibin davranışını değiştirir:

• Geliştiriciler testleri her commit öncesi çalıştırır.
• Pull request inceleyicileri sonucu beklemek zorunda kalmaz.
• Hatalar daha erken yakalanır.
• CI çıktısına güven artar.

Otomatik testlerin yatırım getirisi, ekibin testlere gerçekten güvenmesine bağlıdır.

Ne zaman mock kullanılmamalı?

Mock'un temel hata modu şudur: gerçeklikle artık uyuşmayan bir mock.

Bu durumda testler yeşil kalır, ancak production bozulur. Çünkü testler gerçek sistemi değil, güncelliğini kaybetmiş bir kurguyu doğrular.

Şu durumlarda mock kullanmayın:

• Testin amacı entegrasyonun kendisini doğrulamaksa.
• Sözleşme testi çalıştırıyorsanız.
• Uçtan uca test gerçek kullanıcı akışını doğruluyorsa.
• Mock'ladığınız bağımlılığı hiçbir zaman gerçek servise karşı kontrol etmiyorsanız.
• Gerçek servis test ortamında zaten hızlı, ücretsiz ve güvenilirse.

Genel kural:

Hız, izolasyon ve kontrol için mock kullan.
Doğruluk için küçük ama dürüst bir gerçek servis testi katmanı tut.

Mock ve sözleşme kontrolünü aynı yerde yönetmek istiyorsanız, Apidog API tasarımınızdan mock'lar oluşturur ve testleri hem mock'a hem de canlı endpoint'e karşı çalıştırır. Başlamak için Apidog'u indirin ve mevcut spesifikasyonunuzdan ilerleyin. Kavramsal temel için mock API'nin ne olduğuna da bakabilirsiniz.

Sıkça sorulan sorular

Gerçek API'yi çağırmak yerine ne zaman bir API'yi mock'lamalıyım?

Hız, izolasyon veya kontrole ihtiyacınız olduğunda mock kullanın. Tipik örnekler:

• tamamlanmamış backend'e karşı frontend geliştirme
• gerçek sunucunun üretmeyeceği hata yollarını test etme
• yavaş veya ücretli üçüncü taraf servisleri izole etme
• deterministik demo hazırlama
• CI testlerini kararlı tutma

Sözleşme ve uçtan uca testlerde ise gerçek API'yi çağırın.

Mock kullanımı entegrasyon testinin yerini alır mı?

Hayır. Mock, kontrol ettiğiniz kodu hızlı ve izole test etmek içindir. Entegrasyon ve sözleşme testleri gerçek sınırı doğrulamalıdır. Bu testleri mock'lamak, testin amacını ortadan kaldırır.

Bir mock'un güncelliğini kaybetmesini nasıl önlerim?

Mock'u mümkünse OpenAPI gibi paylaşılan bir şemadan üretin. Sözleşme değiştiğinde mock da aynı kaynaktan güncellenir. Ek olarak, canlı API'ye karşı zamanlanmış sözleşme testleri çalıştırın. Böylece gerçek yanıtın hâlâ beklenen şemayla eşleştiğini doğrularsınız.

Kontrol etmediğim bir üçüncü taraf API'yi mock'layabilir miyim?

Evet. Bu, mock kullanımının en güçlü senaryolarından biridir. Üçüncü tarafın gerçek yanıtlarını kaydedin veya yayınlanmış şemasından mock oluşturun. Testlerinizi mock'a karşı çalıştırın. Satıcı API'si değiştiğinde fark etmek için gerçek servise karşı zamanlanmış bir sözleşme kontrolü ekleyin.

Mock kullanımı demolar ve prototipler için faydalı mı?

Evet. Mock, demoyu izleyicinin görmesini istediğiniz veriyle deterministik hale getirir. Canlı kesinti, boş veri veya yavaş sorgu riski ortadan kalkar. Prototiplerde ise backend hazır olmadan önce UI akışını oluşturmanıza ve doğrulamanıza olanak tanır.