Mock Service Worker (MSW) Alternatifleri: Kapsamlı API Mocking Platformları Ne Zaman Tercih Edilmeli

Ön uç testleri yazıyorsanız, büyük olasılıkla Mock Service Worker (MSW) ile karşılaşmışsınızdır. MSW, tarayıcı ve Node ortamında HTTP isteklerini yakalayarak birim ve bileşen testlerini daha deterministik hale getirir. Bu yazıda MSW’yi ne zaman kullanmanız gerektiğini, nerede yetersiz kalabileceğini ve hangi durumlarda barındırılan bir API sahteleme platformunun daha pratik olduğunu adım adım ele alacağız.

Apidog'u bugün deneyin

Mock Service Worker Nedir?

Mock Service Worker, uygulamanızın yaptığı ağ isteklerini uygulama kodunu değiştirmeden yakalayan bir JavaScript kütüphanesidir.

Tarayıcıda:

• fetch ve XMLHttpRequest çağrılarını yakalamak için Service Worker kullanır.
• Uygulama gerçek API’ye istek atıyor gibi davranır.
• MSW araya girer ve sizin tanımladığınız yanıtı döndürür.

Node ortamında:

• Jest, Vitest veya benzeri test çalıştırıcılarında istek katmanını yamalar.
• Aynı handler yapısını testlerde kullanabilirsiniz.

MSW’nin en güçlü tarafı şudur: uygulama kodunuz gerçek HTTP istemcisini kullanmaya devam eder. fetch’i stub’lamanız, Axios instance’ını değiştirmeniz veya test için ayrı bir istemci yazmanız gerekmez.

MSW’nin nasıl çalıştığını daha derin incelemek isterseniz GitHub’daki MSW kaynak koduna bakabilirsiniz.

Basit bir handler örneği:

import { http, HttpResponse } from 'msw'

export const handlers = [
  http.get('/api/users/:id', ({ params }) => {
    return HttpResponse.json({
      id: params.id,
      name: 'Ada Lovelace',
    })
  }),
]

Bu handler şunu yapar:

1. /api/users/:id yoluna gelen GET isteklerini yakalar.
2. URL parametresindeki id değerini okur.
3. JSON yanıt döndürür.

Test tarafında bu yaklaşım, doğrudan istemciyi mock’lamaktan daha gerçekçi bir akış sağlar.

MSW Nerede En İyi Çalışır?

MSW, sahte API tanımlarının ve API tüketicisinin aynı JavaScript kod tabanında olduğu durumlarda en verimli çözümdür.

1. Bileşen ve Birim Testleri

Bir React veya Vue bileşenini render edip gerçek istek atmasına izin verebilirsiniz. MSW isteği yakalar ve önceden tanımladığınız veriyi döndürür.

Örnek senaryo:

http.get('/api/profile', () => {
  return HttpResponse.json({
    id: 1,
    name: 'Ayşe',
    role: 'admin',
  })
})

Böylece bileşeniniz gerçek API’ye bağlı kalmadan şu durumları test edebilirsiniz:

• Başarılı veri yükleme
• Boş liste
• 404 yanıtı
• 500 sunucu hatası
• Loading state
• Error state

Doğrudan Jest mock kullanımıyla farkını görmek için API çağrısının Jest sahtesi hakkındaki rehbere bakabilirsiniz.

2. Yerel Ön Uç Geliştirme

Backend hazır değilken UI geliştirebilirsiniz.

Örneğin ürün listesi henüz gerçek API’den gelmiyorsa:

http.get('/api/products', () => {
  return HttpResponse.json([
    { id: 1, name: 'Klavye', price: 1200 },
    { id: 2, name: 'Mouse', price: 800 },
  ])
})

Bu sayede frontend ekibi:

• Backend’i beklemeden ekran geliştirebilir.
• Farklı yanıt senaryolarını hızlıca deneyebilir.
• Hata ve boş durum tasarımlarını test edebilir.

3. Deterministik CI Testleri

CI ortamında canlı API’ye bağlanmak testleri kırılgan hale getirir. Ağ sorunları, değişen seed data veya paylaşılan staging ortamı testleri bozabilir.

MSW ile testler:

• Dış servise bağımlı olmaz.
• Aynı input için aynı output’u üretir.
• Daha hızlı ve kararlı çalışır.

4. Tek Dil ve Tek Ekip

Eğer mock’u yazan ve kullanan ekip aynı frontend ekibiyse MSW çok pratiktir. Handler’lar doğrudan repoda durur, versiyonlanır ve pull request sürecine dahil olur.

Kısaca: tek frontend deposu, JavaScript testleri ve lokal geliştirme için MSW genellikle yeterlidir.

MSW Nerede Zorlanır?

MSW’nin güçlü olduğu yer, aynı zamanda sınırıdır: mock tanımları JavaScript kodu olarak belirli bir repo içinde yaşar.

Ekip büyüdüğünde veya farklı istemciler devreye girdiğinde bu model zorlaşabilir.

JavaScript Olmayan Tüketiciler

MSW handler’ları JavaScript’tir. Bu nedenle şu ekipler doğrudan kullanamaz:

• Swift ile iOS geliştiren mobil ekip
• Kotlin ile Android geliştiren ekip
• Go, Python veya Java ile entegrasyon testi yazan backend ekipleri
• Harici partner sistemleri

Örneğin mobil ekip aynı sahte yanıtları kullanmak isterse MSW handler’larını import edemez. Kendi mock sunucularını yazmaları gerekir. Bu da zamanla frontend mock’ları ile mobil mock’larının ayrışmasına yol açabilir.

Bu durumda HTTP üzerinden erişilen, dilden bağımsız bir sahte sunucu daha uygundur.

Paylaşılan ve Her Zaman Açık Mock İhtiyacı

MSW bir işlem içinde çalışır:

• Tarayıcı sekmesinde Service Worker olarak
• Node test sürecinde istek katmanını yamalayarak

Bu nedenle QA mühendisine, tasarımcıya veya başka bir takıma paylaşabileceğiniz sabit bir mock URL’si sunmaz.

Şu ihtiyacınız varsa MSW tek başına yeterli olmayabilir:

• QA ekibi aynı mock API’yi kullanacak.
• Mobil ekip gerçek URL’ye istek atacak.
• Demo ortamında sabit bir endpoint kullanılacak.
• Partner ekip API hazır olmadan entegrasyon geliştirecek.

Bu noktada barındırılan bir mock server daha uygulanabilir olur.

Önce Tasarım ve Şema Odaklı İş Akışları

API’yi önce OpenAPI ile tasarlıyorsanız, mock yanıtlarının da bu şemadan üretilmesi idealdir.

MSW’de handler’ları manuel yazarsınız:

http.get('/api/orders/:id', () => {
  return HttpResponse.json({
    id: 'ord_123',
    status: 'paid',
  })
})

Ancak OpenAPI şemanız değişirse bu handler’ın güncel kalmasını sizin sağlamanız gerekir.

Şema odaklı platformlarda ise mock yanıtları API sözleşmesinden türetilebilir. Bu yaklaşım, mock ile gerçek API sözleşmesinin ayrışmasını azaltır. Daha fazla detay için API sahteleme rehberine bakabilirsiniz.

Ölçekte Gerçekçi Dinamik Veri

MSW size tam kontrol verir, fakat gerçekçi veri üretimini sizin yazmanız gerekir.

Örneğin:

http.get('/api/users', () => {
  return HttpResponse.json([
    {
      id: 1,
      email: '[e-mail]',
      createdAt: '2026-01-01T00:00:00Z',
    },
  ])
})

Bu küçük örneklerde sorun değildir. Ancak çok sayıda endpoint ve alan olduğunda gerçekçi veri üretimi bakım yüküne dönüşebilir.

Şu tür alanlar için sürekli manuel veri yazmanız gerekir:

• email
• phone
• createdAt
• avatar
• address
• price
• status
• uuid

Alan adlarından veri çıkarımı yapabilen platformlar bu yükü azaltabilir.

MSW ile Barındırılan API Mock Platformu Karşılaştırması

Aşağıdaki karşılaştırma hangi aracın hangi problem için daha uygun olduğunu gösterir.

Yetenek	Mock Service Worker	Barındırılan API platformu (örn. Apidog)
JS birim/bileşen testleri içinde çalışır	Evet, yerel	Hayır, bir JS test kütüphanesi değil
HTTP üzerinden dilden bağımsız	Hayır, JavaScript odaklı	Evet, herhangi bir istemci çağırabilir
Tüm ekip için paylaşılan URL	Hayır	Evet, barındırılan mock sunucu
OpenAPI'den mock oluşturma	Manuel	Şemadan otomatik
Akıllı/dinamik veri üretimi	Elle kodlanır	Dahili
Testlerle birlikte repoda yaşar	Evet	Paylaşılan projede saklanır
Maliyet	Ücretsiz, açık kaynak	Ücretsiz katman + ücretli planlar

Özet:

• MSW, frontend testleri ve lokal geliştirme için doğru araçtır.
• Apidog gibi bir platform, mock’un ekipler arasında paylaşılması, farklı dillerden tüketilmesi veya OpenAPI şemasına bağlı kalması gerektiğinde daha uygundur.

Apidog: MSW’nin Yerine Değil, Yanına

Apidog, Jest veya Vitest içinde MSW’nin birebir yerine geçen bir kütüphane değildir. Test dosyanıza import edip request interception yapmaz.

Daha doğru kullanım modeli şudur:

• MSW: frontend repodaki birim ve bileşen testleri
• Apidog: ekipler arası paylaşılan, HTTP tabanlı, şema odaklı mock API

Pratik akış:

1. API’nizi Apidog’da tasarlayın veya OpenAPI şemanızı içe aktarın.
2. Şemadan mock endpoint oluşturun.
3. Oluşan gerçek URL’yi frontend, mobil veya QA ekibiyle paylaşın.
4. Gerekirse özel durumlar için özel mock kuralları ekleyin.
5. Frontend kodunuzu bu mock URL’ye yönlendirin.

Örneğin frontend ortam değişkeniyle mock endpoint’e geçebilir:

VITE_API_BASE_URL=https://your-mock-server.example.com

Ardından uygulama kodunda aynı HTTP istemcisini kullanmaya devam edebilirsiniz:

const response = await fetch(`${import.meta.env.VITE_API_BASE_URL}/users`)
const users = await response.json()

Apidog, alan adlarından veri tipi çıkarımı yaparak daha gerçekçi yanıtlar üretmeye yardımcı olur. Örneğin email adlı bir alan e-posta formatında, createdAt adlı bir alan tarih formatında dönebilir.

Bu yaklaşımın avantajı, mock’un API tasarımıyla aynı şemadan beslenmesidir. Böylece manuel yazılmış handler’ların zamanla sözleşmeden sapma riski azalır.

Şemadan mock oluşturmayı farklı araçlar arasında karşılaştırmak isterseniz en iyi API sahteleme araçları derlemesine göz atabilirsiniz.

Birçok ekip için pratik ayrım şu şekilde olur:

• Frontend deposundaki unit/component testleri için MSW kullanın.
• Mobil, QA, demo ve entegrasyon senaryoları için barındırılan mock sunucu kullanın.
• OpenAPI sözleşmesini tek kaynak olarak tutun.
• Mock yanıtlarının şemadan türetilmesini sağlayın.

Yani seçim yapmak zorunda değilsiniz. MSW ve barındırılan mock platformu farklı katmanlarda birlikte kullanılabilir.

Mevcut MSW kurulumunuzun yanında barındırılan mock tarafını denemek isterseniz Apidog’u indirin.

Bilmeniz Gereken Diğer MSW Alternatifleri

MSW tek seçenek değildir. Kullanım senaryonuza göre farklı araçlar daha uygun olabilir.

• Mockoon: GUI üzerinden hızlıca lokal mock server oluşturmak için masaüstü uygulaması.
• WireMock: Java tabanlı güçlü bir mock server; JVM ekipleri ve sözleşme testleri için uygundur.
• Prism: Stoplight tarafından geliştirilen, OpenAPI dosyasından CLI ile mock server çalıştıran araç.
• json-server: Bir JSON dosyasını hızlıca REST API’ye dönüştürmek için pratik prototipleme aracı.

Genel tercih rehberi:

• Hızlı frontend testleri: MSW
• GUI ile lokal mock: Mockoon
• JVM ve sözleşme testleri: WireMock
• OpenAPI’den CLI mock: Prism
• Basit prototip REST API: json-server
• Ekipler arası paylaşılan mock URL: barındırılan mock platformu

Eğer temel sorununuz “MSW JavaScript dışı ekip arkadaşlarıma yardımcı olmuyor” ise, HTTP üzerinden erişilebilen herhangi bir mock sunucu bu problemi çözebilir.

React tarafındaki örnekleri görmek için React’ta Axios ile API’leri nasıl sahtelediklerini anlatan rehbere bakabilirsiniz.

Sıkça Sorulan Sorular

MSW ücretsiz mi?

Evet. Mock Service Worker, MIT lisansı altında açık kaynaklıdır ve ticari projeler dahil ücretsiz kullanılabilir.

Barındırılan mock platformları ise genellikle ücretsiz katman ve ücretli planlar sunar. Apidog gibi araçlar, paylaşılan mock sunucu ve ekip özellikleri için farklı planlar sağlayabilir.

Apidog, birim testlerimde MSW’nin yerini alabilir mi?

Hayır. Apidog, Jest veya Vitest içinde çalışan bir request interception kütüphanesi değildir.

MSW, JavaScript test çalıştırıcınızın içinde istekleri yakalar. Apidog ise HTTP üzerinden erişilen barındırılan bir platformdur.

Doğru kullanım:

• Birim ve bileşen testleri: MSW
• Paylaşılan mock API: Apidog
• JavaScript dışı tüketiciler: Apidog veya başka HTTP tabanlı mock server

Kod içi yaklaşımları öğrenmek isterseniz API çağrılarını nasıl taklit edeceğiniz hakkındaki rehbere bakabilirsiniz.

MSW Node’da mı çalışır, yoksa sadece tarayıcıda mı?

Her ikisinde de çalışır.

Tarayıcıda:

• Service Worker kullanır.
• Gerçek fetch ve XMLHttpRequest çağrılarını yakalar.

Node’da:

• İstek katmanını yamalar.
• Jest, Vitest veya benzeri test ortamlarında aynı handler mantığını kullanmanızı sağlar.

Bu çift mod, MSW’yi JavaScript tabanlı frontend testleri için güçlü kılar.

MSW’den barındırılan mock sunucuya ne zaman geçmeliyim?

Tam olarak “geçmek” yerine çoğu durumda yanına eklemek daha doğrudur.

Şu sinyaller varsa barındırılan mock sunucu eklemeyi düşünün:

• Mock API’ye mobil ekibin de erişmesi gerekiyor.
• QA ekibi sabit bir URL üzerinden test yapmak istiyor.
• Birden fazla ekip aynı mock davranışını paylaşmalı.
• API’leri OpenAPI ile tasarlıyorsunuz.
• Mock yanıtlarının şemadan otomatik üretilmesini istiyorsunuz.
• Partner veya backend ekipleri JavaScript dışı ortamlardan test yapıyor.

Sonuç

MSW, frontend ve birim testleri için mükemmel bir araçtır. Uygulama kodunu değiştirmeden HTTP isteklerini yakalar, testleri deterministik hale getirir ve JavaScript ekosistemine iyi oturur.

Ancak MSW’nin amacı paylaşılan, barındırılan, dilden bağımsız bir mock API olmak değildir.

Pratik strateji şu şekilde olmalıdır:

• MSW’yi frontend testlerinde kullanın.
• Paylaşılan URL gerektiğinde barındırılan mock sunucu ekleyin.
• OpenAPI şemasını tek sözleşme kaynağı olarak tutun.
• JavaScript dışı tüketiciler için HTTP tabanlı mock sağlayın.

Apidog, bu paylaşılan ve şema odaklı tarafı ele alır: gerçek URL’ye sahip barındırılan mock sunucu, OpenAPI tasarımından otomatik mock üretimi ve gerçekçi veri yanıtları.

MSW’yi güçlü olduğu yerde tutun; test çalıştırıcınızın ötesindeki paylaşılan mock ihtiyaçları için Apidog kullanın.