Kodunuz, kontrol etmediğiniz bir hizmete bağımlıdır. Bir ödeme ağ geçidi, bir iş ortağı API'si, eski bir anabilgisayar, başka bir ekibin mikro hizmeti. Bu bağımlılık bakımda olabilir, test çalıştırmalarınızı hız sınırı uygulayabilir, çağrı başına ücret alabilir veya tutarsız veri döndürebilir. Böylece geliştirmeleriniz durur ve CI ardışık düzeniniz kodunuzla ilgisi olmayan nedenlerle kırmızıya döner.
Servis sanallaştırma bunu düzeltir. Gerçek bağımlılığı, onun gibi davranan bir yedekle değiştirirsiniz, böylece tamamen kontrol ettiğiniz bir şeye karşı geliştirme ve test yapabilirsiniz. Bu kılavuz, servis sanallaştırmasının ne olduğunu, taklit (mocking) ve taslaklamadan (stubbing) nasıl farklılaştığını, ekiplerin neden buna başvurduğunu ve hangi araçların işe yaradığını; WireMock, Hoverfly, Mountebank, kurumsal seçenekler ve API sözleşmesi sanallaştırması için Apidog'un mock sunucusu için gerçek komutlarla birlikte açıklamaktadır.
Servis sanallaştırma nedir
Servis sanallaştırma, kontrol etmediğiniz bir bağımlılığın davranışını simüle eder, böylece uygulamanız gerçek yerine simülasyonla konuşabilir.
"Davranış" kelimesi burada önemlidir. İyi bir sanal hizmet sadece sabit bir yük (payload) döndürmez. İstek detaylarına göre eşleşir, farklı girdiler için farklı yanıtlar döndürür, çağrılar arasında durumu tutar, gecikme ve hatalar enjekte eder ve gerçek sistemle aynı protokolü konuşur. Amaç, kodunuzun geliştirme ve test sırasında farkı anlayamayacağı kadar gerçekçi bir yedek sağlamaktır.
Bağımlılık bir HTTP API olduğunda "API sanallaştırması" terimi aynı anlama gelir ve "API simülatörü" sanal uç noktayı üreten araçtır. Her ikisini de servis sanallaştırmasının API odaklı dilimi için eşanlamlı olarak kabul edin.
Servis sanallaştırma ile taklit (mocking) ve taslaklama (stubbing) karşılaştırması
Bu üç terim birbiriyle örtüşür ve insanlar bunları serbestçe kullanır. İşte onları ayırmanın pratik bir yolu.
Bir taslak (stub), sabit kodlu bir yanıt döndürür. İsteği görmezden gelir ve her zaman aynı şekilde yanıt verir. Testiniz GET /user/42 çağrısı yaparsa ve taslak sabit bir kullanıcı nesnesi döndürecek şekilde ayarlanmışsa, hangi kimliği gönderirseniz gönderin aynı nesneyi döndürür. Taslaklar en basit formdur ve test kodunuzun içinde yaşarlar.
Bir taklit (mock), etkileşimleri de doğrulayan bir taslaktır. Nasıl çağrıldığını (hangi metotlar, hangi argümanlar, kaç kez) kaydeder, böylece testiniz kodunuzun bağımlılığı doğru kullandığını iddia edebilir. Taklitler birim testi aracıdır. Genellikle işlem içi olarak, kodunuzla aynı dilde çalışırlar. API taslaklama ve API taklit etme açıklayıcımız bu ayrımı daha derinlemesine inceler.
Servis sanallaştırma, kodunuzda değil, ağ üzerinden çalışır. Gerçek bir ağ portu üzerinde gerçek bir protokolü konuşan çalışan bir hizmet kurar. Uygulamanız, bir temel URL'yi veya bir proxy ayarını değiştirerek üretime bağlanacağı gibi ona da bağlanır. Bir sanal hizmet durum tutabilir, karmaşık istek koşullarıyla eşleşebilir ve HTTP durum kodları, başlıklar, akış ve bağlantı hataları gibi protokol düzeyinde davranışları simüle edebilir.
"Taklit (mock)" ve "servis sanallaştırma" arasındaki çizgi günlük dilde bulanıktır. Birçok ekip, tam sanallaştırma yapsa bile çalışan bir HTTP mock sunucusuna "mock" der. Bu sorun değil. Önemli olan ayrım: İşleminizin içindeki bir nesneyi mi değiştiriyorsunuz (taklit/taslaklama), yoksa uygulamanızın bağlandığı ağ tabanlı bir hizmet mi kuruyorsunuz (sanallaştırma)? Taklit tarafı için API taklit etme: Bilmeniz gereken her şey bölümüne bakın.
Ekipler neden servis sanallaştırma kullanır?
Üç sorun, çoğu benimsemenin arkasındaki itici güçtür.
Bağımlılık hazır değil. Frontend ve backend ekipleri paralel çalışır ve frontend, backend onu göndermeden önce çalışan bir API'ye ihtiyaç duyar. API sözleşmesinden oluşturulan bir sanal hizmet, frontend'in bugün gerçekçi yanıtlarla çalışmasına olanak tanır. Kimse beklemez.
Bağımlılık pahalı veya hız sınırlı. Üçüncü taraf API'leri genellikle çağrı başına ücret alır veya agresif bir şekilde kısıtlar, bu nedenle canlı bir sanal altyapıya karşı tam bir test paketi çalıştırmak kota ve para yakar. Bir sanal hizmete erişmek ücretsizdir, bu nedenle CI'niz günde binlerce senaryo çalıştırabilir.
Bağımlılık tutarsız veya kontrol etmesi zor. Gerçek bir ödeme sağlayıcısını belirli bir hata döndürmeye, zaman aşımına uğramaya veya hatalı bir yanıt göndermeye kolayca zorlayamazsınız. Bir sanal hizmet, bunların herhangi birini talep üzerine üretir, bu da üretimde bozulan hata yollarını test etmenizi sağlar.
Bir de kontrol avantajı var. Gerçek bağımlılıkların altındaki veriler değişir. Bir sanal hizmet size sabit, bilinen bir durum verir, böylece testleriniz deterministik olur. Yeşil bir derleme, kodunuzun çalıştığı anlamına gelir, uzaktan bir sistemin bugün iyi davrandığı anlamına gelmez.
Servis sanallaştırma nasıl çalışır?
Çoğu araç iki desenden birini takip eder.
Kaydet ve tekrar oynat. Aracı bir proxy olarak gerçek hizmete yönlendirirsiniz, gerçek trafiği bir kez içinden geçirirsiniz ve istek/yanıt çiftlerini yakalar. Daha sonra gerçek hizmeti çağırmak yerine bu kayıtları tekrar oynatır. Yanıtları elle yazmadığınız için bu hızlıdır. Hoverfly'ın yakalama modu ve WireMock'ın kayıt modu bu şekilde çalışır.
Spesifikasyon tabanlı. Sanal hizmeti bir API sözleşmesinden veya elle tanımlarsınız: hangi isteklerin hangi yanıtlarla eşleştiğini bildirir, dinamik değerler ekler ve durum tutan davranışları ayarlarsınız. Öncesinde daha fazla iş gerektirir ancak size tam kontrol sağlar ve gerçek hizmet henüz mevcut olmasa bile çalışır.
Her iki durumda da temel mekanik istek eşleştirmedir. Bir istek geldiğinde, araç onu bir dizi kurala (yol, metot, sorgu parametreleri, başlıklar, gövde) göre kontrol eder ve ilk eşleşmeye bağlı yanıtı döndürür. Daha iyi araçlar şablonlama ekler, böylece bir yanıt isteğin bazı kısımlarını tekrar yansıtabilir veya her çağrıda yeni değerler oluşturabilir. Sanal hizmet bu şekilde statik yerine canlı hissettirir.
Araçlar
İşte açık kaynaklı HTTP odaklı araçlardan ağır kurumsal paketlere kadar ana seçenekler. Hızlı hareket ettikleri için taahhütte bulunmadan önce her projenin kendi belgelerine karşı güncel sürümleri ve özellikleri doğrulayın.
WireMock
WireMock, HTTP için açık kaynaklı API taklit etme ve servis sanallaştırmasıdır. Bağımsız bir işlem olarak, JVM testlerine gömülü olarak veya bir konteynerde çalışır. Taslak eşleştirmelerini JSON olarak tanımlarsınız ve WireMock gelen istekleri bunlara göre eşleştirir. Gerçek bir hizmete karşı kaydet ve tekrar oynatma, yanıt şablonlama, durum tutan senaryolar, hata enjeksiyonu ve simüle edilmiş gecikmeleri destekler.
Bağımsız JAR'ı çalıştırın:
java -jar wiremock-standalone-3.13.2.jar --port 8080
Ardından yönetici API'si üzerinden bir taslak kaydedin:
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" }
}
}'
WireMock, bağımlılıklarınız HTTP olduğunda ve JVM veya konteynerli kurulumlarda hassas kontrol istediğinizde en güçlüsüdür. Yönetilen bir seçenek isterseniz ticari barındırılan bir sürümü (WireMock Cloud) de mevcuttur.
Hoverfly
Hoverfly, Go dilinde yazılmış hafif, açık kaynaklı bir servis sanallaştırma aracıdır. Bir proxy olarak çalışır: uygulamanızın giden trafiğini Hoverfly üzerinden yönlendirirsiniz ve Hoverfly ya gerçek yanıtları kaydeder ya da simüle edilmiş olanları tekrar oynatır. Yakalama, simülasyon, casusluk (spy), değiştirme, sentezleme ve fark (diff) dahil olmak üzere çeşitli modlarda çalışır.
hoverctl komutunu kullanarak temel bir yakala-sonra-oynat akışı:
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
Hoverfly'ın yönetici API'si varsayılan olarak 8888 portunda, proxy'si ise 8500 portunda çalışır. Kaydet ve tekrar oynatma proxy modeli, her yanıtı elle yazmak yerine mevcut trafiği hızlı bir şekilde sanallaştırmak istediğinizde onu iyi bir seçim yapar. Barındırılan bir Hoverfly Cloud da mevcuttur.
Mountebank
Mountebank, "imposters" etrafında oluşturulmuş açık kaynaklı bir araçtır. Bir imposter, tek bir portta dinleyen ve tek bir protokol konuşan tek bir sanal hizmettir. HTTP ve HTTPS'in ötesinde, Mountebank TCP ve SMTP'yi de işler, bu da bağımlılığınız düz bir REST API olmadığında kullanışlıdır. Kontrolünü tamamen 2525 portundaki bir REST kontrol düzlemi üzerinden yaparsınız.
Kurun ve başlatın:
npm install -g mountebank
mb
Ardından kontrol portuna JSON POST ederek bir 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, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
}]
}'
Predikatlar hangi isteğin eşleştiğine karar verir; yanıtlar neyin geri geleceğini tanımlar. Mountebank'in çoklu protokol erişimi, açık kaynak seçenekleri arasında onu farklılaştıran özelliğidir.
Parasoft Virtualize ve Broadcom Service Virtualization
Büyük işletmeler için en güçlü seçenekler Parasoft Virtualize ve Broadcom Service Virtualization'dır (DevTest paketinin bir parçası). Bunlar, HTTP'nin ötesinde birçok protokolü ve mesaj formatını simüle etmesi, sanal hizmetleri gerçek veri kaynaklarına bağlaması ve birçok ortamda sanallaştırmayı merkezi olarak yönetmesi gereken ekipler için oluşturulmuş ticari platformlardır.
Parasoft Virtualize, geniş bir yelpazede endüstri standardı protokolleri ve mesaj formatlarını, ayrıca harici veri kaynaklarından beslenen veri odaklı sanal hizmetleri desteklediğini duyurmaktadır. Broadcom'un teklifi, paralel geliştirme ve test için sanallaştırılmış ortamlarla benzer kurumsal senaryoları hedeflemektedir. Her ikisi de kurumsal lisanslama ve kurulum yükü taşır, bu nedenle birkaç REST uç noktası yerine eski protokolleri (anabilgisayar, MQ, sabit uzunluklu mesajlar) ölçekli olarak sanallaştırdığınızda uygundur. Bağımlılıklarınız sıradan HTTP API'leri ise, yukarıdaki açık kaynak araçlar veya bir API platformu sizi maliyetin çok altında karşılar. Güncel protokol listelerini ve fiyatlandırmayı her 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 bir sözleşmeyle tanımlanmış bir HTTP API ise, Apidog bu dilimi ayrı bir araç olmadan kapsar. Bir API tasarladığınızda veya içe aktardığınızda, Apidog otomatik olarak onun için bir mock sunucusu kurar. Frontend'iniz veya test paketiniz, herhangi bir backend kodu mevcut olmadan önce, yalnızca şemadan çalışan bir uç nokta alır.
Bunu düz bir taslaktan çok sanallaştırmaya yaklaştıran şey, Apidog'un mock'unun şema farkındalıklı ve dinamik olmasıdır. Akıllı Mock'u, JSON Şemanızı okur ve her kısıtlamayı (türler, formatlar, enum'lar, gerekli alanlar) gözeten yanıtlar üretir. Ayrıca alan adlarını yerleşik kurallarla eşleştirir, böylece email adlı bir alan geçerli bir e-posta, city adlı bir alan ise yer tutucu önemsiz veriler yerine bir şehir adı döndürür. Daha hassas kontrol için, Faker.js tabanlı dinamik değerler her çağrıda gerçekçi veriler üretir ve determinizm ihtiyacınız olduğunda sabit değerleri sabitleyebilirsiniz.
Ayrıca, isteğe bağlı parametrelere göre farklı yanıtlar döndüren özel mock kuralları yazabilirsiniz; bu, sanallaştırmayı sabit bir taslaktan ayıran istek eşleştirme davranışıdır. Mock sunucusu GUI'de veya başsız (headless) olarak çalışır, bu nedenle hem yerel geliştirmeye hem de CI'a uyar. Bir gözden geçirme için bir API'yi bir dakikada nasıl taklit edeceğinize bakın.
Apidog'un uyduğu yer: HTTP/REST ve benzerleri için API sözleşmesi servis sanallaştırması. Uymadığı yer: rastgele eski protokoller için proxy tabanlı bir kaydet ve tekrar oynat aracı değildir ve bir yük oluşturucu değildir. Bunlar için yukarıdaki araçlar doğru seçimdir. Daha geniş bir araç karşılaştırması için çevrimiçi API taklit araçları karşılaştırıldı ve en iyi 10 API taklit aracı bölümlerine bakın.
Nasıl Başlanır
Aracı bağımlılığa uydurun, tersini değil.
- Protokolü belirleyin. Düz HTTP/REST mi? Burada hemen hemen her şey işe yarar ve bir API platformu en az sürtünmeyi sağlar. TCP veya SMTP mi gerekiyor? Mountebank. Büyük ölçekli eski kurumsal protokoller mi? Parasoft veya Broadcom.
- Kaydetme mi yoksa belirtme mi olduğuna karar verin. Gerçek hizmet mevcutsa ve trafiği onun üzerinden yönlendirebiliyorsanız, kaydet ve tekrar oynat (Hoverfly, WireMock kayıt modu) en hızlısıdır. Henüz mevcut değilse, sanal hizmeti API sözleşmesinden yönetin (Apidog, WireMock taslakları, Mountebank imposters).
- Uygulamanızı ona yönlendirin. Test veya geliştirme ortamınızda bir temel URL'yi veya proxy ayarını değiştirin ve sanal ile gerçek arasında geçişin tek bir değişken olması için bunu yapılandırmanın arkasında tutun.
- Hata durumlarını ekleyin. Kazanım, hata yollarını test etmektir, bu nedenle 4xx ve 5xx, zaman aşımı ve bozuk gövdeler için yanıtlar ekleyin. Bu, gerçek bağımlılıkların size prova etmenize izin vermeyeceği kısımdır.
- CI'da çalıştırın. Yalnızca dizüstü bilgisayarınızda çalışan bir sanal hizmet size yardımcı olur ama derlemeye değil. Boru hattına koyun ki yeşil, yeşil anlamına gelsin. CI'da GUI olmadan başsız (headless) çalışan bir mock'a ihtiyacınız varsa, başsız API mock araçlarına bakın.
Genel olarak sanal ve canlı bağımlılıklar arasındaki denge için, mock sunucusu ve gerçek sunucu her birinin ne zaman kullanılacağını açıklar.
SSS
Servis sanallaştırma, taklit (mocking) ile aynı mıdır? Tam olarak değil. Taklit, genellikle birim testleri için işleminizin içindeki bir nesneyi değiştirir ve nasıl çağrıldığını doğrular. Servis sanallaştırma, uygulamanızın gerçek bir protokol üzerinden bağlandığı bir ağ portunda çalışan bir hizmet kurar. İnsanlar gündelik kullanımda HTTP sanal hizmetlerine "mock" derler ki bu sorun değil, ancak teknik ayrım işlem içi nesne ve ağ hizmetidir.
Gerçek bir test ortamı yerine ne zaman sanal bir hizmet kullanmalıyım? Gerçek bağımlılık kullanılamadığında, hız sınırlı olduğunda, pahalı olduğunda veya kontrol etmesi zor olduğunda sanallaştırmayı kullanın. Size deterministik, ücretsiz, her zaman kullanılabilir yanıtlar verir ve gerçek sistemde tetikleyemeyeceğiniz hataları simüle etmenizi sağlar. Nihai entegrasyon güveni için gerçek hizmete karşı daha küçük bir test kümesini tutun.
Sanal bir hizmet durum tutabilir mi? Evet. WireMock ve Mountebank gibi araçlar, yanıtın önceki isteklere göre değiştiği durum tutan senaryoları destekler; örneğin, boş bir sepet döndürme, ardından bir POST'tan sonra öğelerle dolu bir sepet döndürme. Bu, tek çağrılar yerine iş akışlarını simüle ettiğinizde önemlidir.
Ücretli bir kurumsal araca ihtiyacım var mı? Yalnızca birçok HTTP dışı protokolü sanallaştırıyorsanız veya büyük bir organizasyonda sanallaştırmayı yönetiyorsanız. Sıradan HTTP API'leri için, açık kaynak araçlar (WireMock, Hoverfly, Mountebank) veya bir API platformu mock sunucusu, kurumsal lisanslama olmadan bu işi halleder.
Bir HTTP API'yi spesifikasyonundan sanallaştırmanın en hızlı yolu nedir? API tanımını şemadan bir mock oluşturan bir araca aktarın. Apidog bunu otomatik olarak yapar: OpenAPI spesifikasyonunuzu içe aktardığınızda, gerçekçi dinamik verilerle şema farkındalıklı bir mock sunucusu elde edersiniz, yanıt yazmaya gerek kalmaz. Oradan, testlerinizin ihtiyaç duyduğu belirli istek/yanıt koşulları için özel kurallar eklersiniz.