DEV Community

Cover image for Servis Sanallaştırma: Nedir ve Kullanılan Araçlar
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

Servis Sanallaştırma: Nedir ve Kullanılan Araçlar

Kodunuz çoğu zaman kontrol etmediğiniz servislerle çalışır: ödeme ağ geçidi, iş ortağı API’si, legacy anabilgisayar, başka bir ekibin mikroservisi. Bu servis bakımda olabilir, rate limit uygulayabilir, çağrı başına ücret alabilir veya tutarsız veri döndürebilir. Sonuç: geliştirme yavaşlar, CI pipeline’ı ise kodunuzdan bağımsız nedenlerle kırmızıya döner.

Apidog'u bugün deneyin

Servis sanallaştırma bu problemi pratik şekilde çözer: gerçek bağımlılığı, aynı protokolü konuşan ve kontrol ettiğiniz bir sanal servisle değiştirirsiniz. Böylece geliştirme, test ve CI süreçlerini deterministik hale getirirsiniz. Bu yazıda servis sanallaştırmanın ne olduğunu, mocking/stubbing’den nasıl ayrıldığını, hangi durumda hangi aracı seçeceğinizi ve WireMock, Hoverfly, Mountebank ile Apidog mock sunucusunu nasıl kullanacağınızı göreceksiniz.

Servis sanallaştırma nedir?

Servis sanallaştırma, uygulamanızın bağımlı olduğu gerçek bir servisin davranışını simüle eden çalışan bir yedek servis kurmaktır.

Buradaki önemli kelime davranış. İyi bir sanal servis yalnızca sabit JSON döndürmez. Şunları yapabilir:

  • HTTP metodu, path, query parametresi, header veya body’ye göre istek eşleştirir.
  • Farklı girdiler için farklı yanıtlar döndürür.
  • Çağrılar arasında durum tutar.
  • Gecikme, timeout, 4xx/5xx ve bozuk yanıtlar üretir.
  • Gerçek servisle aynı protokolü konuşur.

Örneğin uygulamanız normalde şu URL’ye gidiyorsa:

PAYMENT_API_BASE_URL=https://payments.example.com
Enter fullscreen mode Exit fullscreen mode

Test ortamında bunu sanal servise yönlendirirsiniz:

PAYMENT_API_BASE_URL=http://localhost:8080
Enter fullscreen mode Exit fullscreen mode

Uygulama açısından değişen tek şey base URL olur. Kodunuz gerçek servise değil, kontrol ettiğiniz sanal servise konuşur.

Bağımlılık bir HTTP API ise buna çoğu zaman API sanallaştırması veya API simülasyonu da denir.

Servis sanallaştırma, mocking ve stubbing farkı

Bu terimler pratikte karışır. Ayırmak için şu soruyu sorun:

Bağımlılığı kodun içinde mi değiştiriyorum, yoksa uygulamanın ağ üzerinden bağlandığı çalışan bir servis mi kuruyorum?

Stub

Stub, genellikle sabit kodlu yanıt döndürür.

Örneğin testte GET /user/42 çağrısı için her zaman aynı kullanıcıyı döndürür:

{
  "id": 42,
  "name": "Ada Lovelace"
}
Enter fullscreen mode Exit fullscreen mode

Çoğu stub, isteğin detaylarıyla fazla ilgilenmez. Basittir ve genellikle test kodunun içinde yaşar.

Mock

Mock, stub’a ek olarak etkileşimleri doğrular.

Örneğin:

  • Bu fonksiyon çağrıldı mı?
  • Kaç kez çağrıldı?
  • Hangi argümanlarla çağrıldı?

Mock’lar çoğunlukla birim testlerinde kullanılır ve uygulama süreci içinde çalışır. Daha detaylı ayrım için API taslaklama ve API taklit etme yazısına bakabilirsiniz.

Servis sanallaştırma

Servis sanallaştırma, ağ seviyesinde çalışır. Uygulamanız gerçek bir porttaki gerçek bir protokole bağlanır.

Örneğin:

curl http://localhost:8080/user/42
Enter fullscreen mode Exit fullscreen mode

Bu istek, gerçek API yerine sanal servise gider. Sanal servis:

  • İstekleri eşleştirir.
  • Yanıt üretir.
  • Hata senaryolarını simüle eder.
  • Gerektiğinde durum tutar.

Günlük kullanımda çalışan HTTP sanal servislerine de “mock server” denir. Bu kullanım sorun değildir. Teknik ayrım şudur:

  • Mock/stub: işlem içindeki nesne
  • Servis sanallaştırma: ağ üzerinden erişilen çalışan servis

API mocking tarafı için ayrıca API taklit etme: Bilmeniz gereken her şey yazısına bakabilirsiniz.

Ekipler neden servis sanallaştırma kullanır?

1. Bağımlılık henüz hazır değildir

Frontend ekibi endpoint’e ihtiyaç duyar, backend ekibi ise API’yi henüz tamamlamamıştır.

Bu durumda OpenAPI gibi bir sözleşmeden mock servis üretirsiniz. Frontend bugün geliştirmeye başlar.

Örnek akış:

  1. API sözleşmesini tanımlayın.
  2. Sanal servis oluşturun.
  3. Frontend’in base URL’ini mock sunucuya yönlendirin.
  4. Backend hazır olduğunda aynı sözleşmeye göre gerçek servise geçin.

2. Bağımlılık pahalı veya rate limited olabilir

Üçüncü taraf API’ler genellikle:

  • Çağrı başına ücret alır.
  • Günlük kota uygular.
  • Test trafiğini kısıtlar.

CI pipeline’ında yüzlerce testin gerçek API’ye gitmesi maliyetli ve kırılgandır. Sanal servisle aynı senaryoları ücretsiz ve hızlı çalıştırabilirsiniz.

3. Bağımlılığı istediğiniz hataya zorlayamazsınız

Gerçek ödeme sağlayıcısını kolayca şunlara zorlayamazsınız:

  • 500 dön
  • Timeout üret
  • Eksik alanlı JSON gönder
  • Bozuk response body döndür
  • 2 saniye gecik

Sanal servisle bu senaryoları doğrudan tanımlarsınız.

Örneğin timeout davranışını test etmek istiyorsanız sanal servise gecikme ekleyebilirsiniz:

{
  "response": {
    "status": 200,
    "fixedDelayMilliseconds": 5000,
    "jsonBody": {
      "status": "ok"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Bu sayede production’da bozulabilecek hata yollarını önceden test edersiniz.

Servis sanallaştırma nasıl çalışır?

Çoğu araç iki yaklaşımdan birini kullanır.

1. Kaydet ve tekrar oynat

Bu modelde aracı proxy olarak gerçek servisin önüne koyarsınız.

Akış:

  1. Uygulama isteği sanallaştırma aracına gönderir.
  2. Araç isteği gerçek servise iletir.
  3. Gerçek yanıtı kaydeder.
  4. Daha sonra gerçek servise gitmeden aynı yanıtı tekrar oynatır.

Bu yaklaşım özellikle mevcut bir API’yi hızlıca sanallaştırmak için uygundur.

Kullanım senaryosu:

  • Gerçek servis çalışıyor.
  • Örnek trafik üretilebiliyor.
  • Yanıtları elle yazmak istemiyorsunuz.

Hoverfly capture modu ve WireMock recording modu bu şekilde çalışır.

2. Spesifikasyon tabanlı sanallaştırma

Bu modelde sanal servisi API sözleşmesinden veya elle tanımlarsınız.

Akış:

  1. Endpoint’leri tanımlayın.
  2. İstek eşleştirme kurallarını yazın.
  3. Yanıt şemalarını veya örneklerini belirleyin.
  4. Gerekirse dinamik veri ve hata senaryoları ekleyin.

Bu yaklaşım özellikle şu durumlarda kullanışlıdır:

  • Gerçek servis henüz yoktur.
  • Önce API sözleşmesiyle geliştirme yapmak istiyorsunuz.
  • Yanıtları tamamen kontrol etmek istiyorsunuz.

Temel mekanizma her zaman istek eşleştirmedir:

Gelen istek
  -> method kontrolü
  -> path kontrolü
  -> query/header/body kontrolü
  -> eşleşen yanıtı döndür
Enter fullscreen mode Exit fullscreen mode

Araçlar

Aşağıdaki araçlar farklı ihtiyaçlara uygundur. Seçim yaparken önce protokolü, sonra çalışma modelini belirleyin.

WireMock

WireMock, HTTP için açık kaynaklı API mocking ve servis sanallaştırma aracıdır. Bağımsız süreç, JVM testlerine gömülü kullanım veya container içinde çalıştırma seçenekleri vardır.

Desteklediği tipik özellikler:

  • JSON ile stub tanımı
  • Request matching
  • Record/replay
  • Response templating
  • Stateful scenarios
  • Fault injection
  • Simüle gecikme

Bağımsız JAR olarak çalıştırın:

java -jar wiremock-standalone-3.13.2.jar --port 8080
Enter fullscreen mode Exit fullscreen mode

Bir endpoint stub’ı ekleyin:

curl -X POST http://localhost:8080/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "method": "GET",
      "url": "/user/42"
    },
    "response": {
      "status": 200,
      "headers": {
        "Content-Type": "application/json"
      },
      "jsonBody": {
        "id": 42,
        "name": "Ada Lovelace"
      }
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Test edin:

curl http://localhost:8080/user/42
Enter fullscreen mode Exit fullscreen mode

Beklenen yanıt:

{
  "id": 42,
  "name": "Ada Lovelace"
}
Enter fullscreen mode Exit fullscreen mode

Hata senaryosu eklemek için ayrı bir mapping tanımlayabilirsiniz:

curl -X POST http://localhost:8080/__admin/mappings \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "method": "GET",
      "url": "/user/500"
    },
    "response": {
      "status": 500,
      "headers": {
        "Content-Type": "application/json"
      },
      "jsonBody": {
        "error": "upstream_failure"
      }
    }
  }'
Enter fullscreen mode Exit fullscreen mode

WireMock özellikle HTTP bağımlılıklarında hassas kontrol istiyorsanız güçlüdür. Yönetilen servis tercih ediyorsanız ticari WireMock Cloud seçeneği de vardır.

Hoverfly

Hoverfly, Go ile yazılmış hafif ve açık kaynaklı bir servis sanallaştırma aracıdır. Proxy modeliyle çalışır.

Tipik kullanım:

  1. Hoverfly’ı başlatın.
  2. Capture moduna alın.
  3. Gerçek API trafiğini Hoverfly üzerinden geçirin.
  4. Simülasyonu dışa aktarın.
  5. Simulate modunda tekrar oynatın.

Temel akış:

hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
Enter fullscreen mode Exit fullscreen mode

Hoverfly’da varsayılan portlar:

  • Admin API: 8888
  • Proxy: 8500

Kaydedilen simülasyonu daha sonra tekrar içe alabilirsiniz:

hoverctl import simulation.json
hoverctl mode simulate
Enter fullscreen mode Exit fullscreen mode

Hoverfly şu durumda iyi seçimdir:

  • Gerçek servis mevcut.
  • Trafiği hızlıca kaydetmek istiyorsunuz.
  • Her yanıtı elle yazmak istemiyorsunuz.
  • Proxy tabanlı record/replay modeli işinize uyuyor.

Barındırılan Hoverfly Cloud seçeneği de mevcuttur.

Mountebank

Mountebank, “imposter” kavramı üzerine kurulu açık kaynaklı bir araçtır.

Bir imposter:

  • Tek bir portta dinler.
  • Tek bir protokol konuşur.
  • Belirli predicate’lere göre yanıt döndürür.

Mountebank yalnızca HTTP/HTTPS değil, TCP ve SMTP gibi protokolleri de destekler. Bu yüzden bağımlılığınız klasik REST API değilse kullanışlıdır.

Kurulum:

npm install -g mountebank
Enter fullscreen mode Exit fullscreen mode

Başlatma:

mb
Enter fullscreen mode Exit fullscreen mode

Varsayılan kontrol portu 2525tir.

Bir HTTP imposter oluşturun:

curl -X POST http://localhost:2525/imposters \
  -H "Content-Type: application/json" \
  -d '{
    "port": 4545,
    "protocol": "http",
    "stubs": [{
      "predicates": [{
        "equals": {
          "method": "GET",
          "path": "/user/42"
        }
      }],
      "responses": [{
        "is": {
          "statusCode": 200,
          "headers": {
            "Content-Type": "application/json"
          },
          "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}"
        }
      }]
    }]
  }'
Enter fullscreen mode Exit fullscreen mode

Test edin:

curl http://localhost:4545/user/42
Enter fullscreen mode Exit fullscreen mode

Predicate, isteğin eşleşip eşleşmediğini belirler. Response ise dönecek yanıtı tanımlar.

Mountebank’i özellikle şu durumlarda değerlendirin:

  • HTTP dışı protokol gerekir.
  • TCP veya SMTP sanallaştırmanız gerekir.
  • Basit bir REST kontrol düzlemiyle sanal servis yönetmek istersiniz.

Parasoft Virtualize ve Broadcom Service Virtualization

Parasoft Virtualize ve Broadcom Service Virtualization, daha büyük kurumsal ihtiyaçlara yönelik ticari platformlardır.

Bu araçlar genellikle şu durumlarda anlamlıdır:

  • Çok sayıda protokol sanallaştırmanız gerekir.
  • Legacy sistemler vardır.
  • Anabilgisayar, MQ veya sabit uzunluklu mesaj formatları gibi yapılar kullanılır.
  • Sanallaştırmayı merkezi olarak yönetmeniz gerekir.
  • Birçok ekip ve ortam aynı sanal servisleri kullanır.

Parasoft Virtualize, farklı endüstri standardı protokol ve mesaj formatlarını, ayrıca harici veri kaynaklarıyla beslenen veri odaklı sanal servisleri desteklediğini belirtir. Broadcom’un çözümü de paralel geliştirme ve test için sanallaştırılmış ortamları hedefler.

Ancak birkaç HTTP endpoint’i sanallaştıracaksanız bu seviyede bir platform genellikle fazla ağır olur. Böyle durumlarda WireMock, Hoverfly, Mountebank veya API platformu tabanlı mock sunucuları daha düşük maliyetli ve daha hızlı uygulanabilir seçeneklerdir.

Güncel protokol desteğini, lisanslamayı ve kurulum gereksinimlerini her zaman ilgili tedarikçiyle doğrulayın.

Apidog: API sözleşmeleri için hafif servis sanallaştırma

Sanallaştırmanız gereken bağımlılık sözleşmeyle tanımlanmış bir HTTP API ise Apidog, ayrı bir servis sanallaştırma aracı kurmadan bu ihtiyacı karşılayabilir.

Tipik kullanım akışı:

  1. API’yi Apidog’da tasarlayın veya içe aktarın.
  2. OpenAPI/şema üzerinden endpoint’leri tanımlayın.
  3. Apidog’un otomatik mock sunucusunu kullanın.
  4. Frontend veya test suite’i bu mock URL’ye yönlendirin.
  5. Gerekirse özel mock kuralları ekleyin.

Bu yaklaşım özellikle backend hazır değilken frontend geliştirmek için pratiktir.

Apidog mock sunucusunu düz stub’dan daha kullanışlı yapan özellik, şema farkındalıklı ve dinamik yanıt üretmesidir. Smart Mock, JSON Schema tanımını okuyarak şu kısıtları dikkate alan veriler üretebilir:

  • Tipler
  • Formatlar
  • Enum değerleri
  • Zorunlu alanlar
  • Alan adlarına göre anlamlı örnek veriler

Örneğin:

  • email alanı geçerli e-posta formatında veri alır.
  • city alanı şehir adı benzeri veri alır.
  • Enum alanları sözleşmedeki geçerli değerlerden seçilir.

Daha fazla kontrol gerektiğinde Faker.js tabanlı dinamik değerler kullanabilir veya deterministik testler için sabit değerler tanımlayabilirsiniz.

Ayrıca isteğe göre farklı yanıtlar döndüren özel mock kuralları yazabilirsiniz. Örneğin:

  • status=pending için bekleyen sipariş yanıtı
  • status=paid için ödenmiş sipariş yanıtı
  • Eksik token için 401
  • Yetkisiz rol için 403

Bu, servis sanallaştırmanın temel parçası olan request matching davranışını sağlar.

Bir API’yi hızlıca mock’lamak için bir API’yi bir dakikada nasıl taklit edeceğinize bakabilirsiniz.

Apidog’un uygun olduğu alan:

  • HTTP/REST API’leri
  • OpenAPI veya şema tabanlı sözleşmeler
  • Frontend/backend paralel geliştirme
  • API dokümantasyonu ve mock’un aynı yerde yönetilmesi
  • CI’da kullanılabilecek headless mock senaryoları

Uygun olmadığı alan:

  • Rastgele legacy protokoller
  • Proxy tabanlı record/replay ihtiyacı
  • Yük testi veya load generation

Daha geniş karşılaştırma için çevrimiçi API taklit araçları karşılaştırıldı ve en iyi 10 API taklit aracı yazılarına bakabilirsiniz.

Nasıl başlanır?

Aracı bağımlılığa göre seçin. Tersini yapmayın.

1. Protokolü belirleyin

Önce bağımlılığın hangi protokolü konuştuğunu netleştirin.

İhtiyaç Uygun seçenek
HTTP/REST API WireMock, Hoverfly, Apidog
OpenAPI sözleşmesinden mock Apidog
Record/replay proxy Hoverfly, WireMock
TCP veya SMTP Mountebank
Legacy kurumsal protokoller Parasoft, Broadcom

2. Kaydetme mi, sözleşme mi kullanacağınıza karar verin

Gerçek servis mevcutsa ve örnek trafik üretebiliyorsanız:

record/replay seçin
Enter fullscreen mode Exit fullscreen mode

Uygun araçlar:

  • Hoverfly
  • WireMock recording mode

Gerçek servis henüz yoksa veya önce sözleşmeyle ilerliyorsanız:

specification-based mock seçin
Enter fullscreen mode Exit fullscreen mode

Uygun araçlar:

  • Apidog
  • WireMock stubs
  • Mountebank imposters

3. Uygulamanızı sanal servise yönlendirin

Base URL’i config üzerinden yönetin.

Örnek:

# local
USER_API_BASE_URL=http://localhost:8080

# staging
USER_API_BASE_URL=https://staging-api.example.com

# production
USER_API_BASE_URL=https://api.example.com
Enter fullscreen mode Exit fullscreen mode

Kod içinde URL sabitlemeyin. Böylece gerçek servis ve sanal servis arasında geçiş tek environment variable ile yapılır.

4. Başarılı yanıtla yetinmeyin

Servis sanallaştırmanın asıl değeri hata senaryolarıdır.

En az şu durumları ekleyin:

  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
  • 409 Conflict
  • 429 Too Many Requests
  • 500 Internal Server Error
  • Timeout
  • Yavaş yanıt
  • Eksik veya bozuk response body

Örnek test matrisi:

Senaryo Beklenen uygulama davranışı
API 200 döner Veri gösterilir
API 401 döner Kullanıcı login’e yönlendirilir
API 429 döner Retry veya hata mesajı gösterilir
API timeout olur Kullanıcıya tekrar dene mesajı gösterilir
API bozuk JSON döner Uygulama kontrollü hata verir

5. CI pipeline’a ekleyin

Sanal servis yalnızca lokal makinede çalışıyorsa faydası sınırlıdır. CI’da da çalıştırın.

Örnek Docker tabanlı yaklaşım:

services:
  wiremock:
    image: wiremock/wiremock
    ports:
      - "8080:8080"
Enter fullscreen mode Exit fullscreen mode

Test job’ında uygulama config’ini sanal servise yönlendirin:

USER_API_BASE_URL=http://wiremock:8080
Enter fullscreen mode Exit fullscreen mode

CI’da GUI olmadan çalışan mock ihtiyacınız varsa başsız API mock araçlarına bakabilirsiniz.

Canlı ve sanal bağımlılıkların dengesini kurmak için mock sunucusu ve gerçek sunucu yazısı da faydalıdır.

Pratik seçim rehberi

Kısa karar ağacı:

Bağımlılık HTTP/REST mi?
  Evet:
    API sözleşmeniz var mı?
      Evet -> Apidog veya WireMock
      Hayır:
        Gerçek trafik kaydedilebilir mi?
          Evet -> Hoverfly veya WireMock recording
          Hayır -> WireMock ile manuel stub
  Hayır:
    TCP/SMTP mi?
      Evet -> Mountebank
      Hayır -> Kurumsal servis sanallaştırma araçlarını değerlendirin
Enter fullscreen mode Exit fullscreen mode

SSS

Servis sanallaştırma mocking ile aynı mıdır?

Tam olarak değil. Mocking genellikle uygulama süreci içinde bir nesneyi değiştirir ve nasıl çağrıldığını doğrular. Servis sanallaştırma ise uygulamanın gerçek bir protokol üzerinden bağlandığı ağ portunda çalışan bir servis kurar.

HTTP sanal servislerine günlük kullanımda “mock server” denmesi yaygındır. Teknik ayrım işlem içi nesne ile ağ servisi arasındadır.

Gerçek test ortamı yerine ne zaman sanal servis kullanmalıyım?

Şu durumlarda sanal servis kullanın:

  • Gerçek bağımlılık hazır değilse
  • Rate limit varsa
  • Çağrılar ücretliyse
  • Veri tutarsızsa
  • Hata senaryolarını tetiklemek zorsa
  • CI testlerinin deterministik olması gerekiyorsa

Yine de nihai entegrasyon güveni için gerçek servise karşı daha küçük bir test seti tutmak iyi pratiktir.

Sanal servis durum tutabilir mi?

Evet. WireMock ve Mountebank gibi araçlar stateful scenario destekler.

Örneğin:

  1. İlk GET /cart boş sepet döndürür.
  2. POST /cart/items çağrısı yapılır.
  3. Sonraki GET /cart ürün içeren sepet döndürür.

Bu, tekil endpoint testlerinden çok iş akışı testlerinde önemlidir.

Ücretli kurumsal araca ihtiyacım var mı?

Çoğu HTTP API için hayır.

Açık kaynak araçlar veya API platformu mock sunucuları genellikle yeterlidir:

  • WireMock
  • Hoverfly
  • Mountebank
  • Apidog mock sunucusu

Kurumsal araçlar daha çok şu durumlarda anlamlıdır:

  • HTTP dışı çok sayıda protokol
  • Legacy sistemler
  • Merkezi yönetim ihtiyacı
  • Büyük organizasyon ölçeği
  • Karmaşık veri kaynaklarıyla beslenen sanal servisler

Bir HTTP API’yi spesifikasyonundan sanallaştırmanın en hızlı yolu nedir?

API tanımını şemadan mock üretebilen bir araca aktarın.

Apidog’da tipik akış:

  1. OpenAPI spesifikasyonunu içe aktarın.
  2. Otomatik mock sunucusunu kullanın.
  3. Frontend veya testleri mock URL’ye yönlendirin.
  4. Gerekirse özel request/response kuralları ekleyin.

Böylece backend kodu hazır olmadan, şema farkındalıklı ve dinamik veriler döndüren bir sanal API ile geliştirme yapabilirsiniz.

Top comments (0)