Canlı bir API'ye bağlı olan testler, yanlış nedenlerle başarısız olan testlerdir. Bir hazırlık sunucusu çöker, üçüncü taraf bir hız limiti devreye girer, bir ekip arkadaşı bir kaydı değiştirir ve kodunuz iyi olsa bile aniden paketiniz kırmızıya döner. API'yi taklit etmek bu kırılganlığı ortadan kaldırır. Gerçek uç noktayı, tam olarak istediğiniz yanıtı her seferinde veren kontrollü bir yedekle değiştirirsiniz.
Bu kılavuz, bir API'yi test için taklit etmenin gerçek adımlarını anlatır. Bir şema tanımlayacak, taklit yanıtlar oluşturacak, test kodunuzu taklit sunucuya yönlendirecek ve gerçek bir sunucunun nadiren isteğe bağlı olarak ürettiği hata yollarını ele alacaksınız. Örnekler küçük bir sipariş yönetimi API'si kullanır, ancak iş akışı herhangi bir REST veya GraphQL hizmeti için geçerlidir.
API'yi taklit etmenin doğru karar olduğu zamanlar
Test etmek istediğiniz şey ağ değil, kendi kodunuz olduğunda API'yi taklit edin. Birim testleri ve çoğu entegrasyon testi bu kategoriye girer. İstemcinizin bir 200'ü doğru ayrıştırdığını, bir 503'te yeniden denediğini ve bir 404'te açık bir mesaj gösterdiğini bilmek istersiniz. Bunların hiçbiri gerçek bir sunucu gerektirmez.
Gerçek API'yi sözleşme testleri ve ince bir uçtan uca kontrol katmanı için saklayın. Bunlar, taklitin hala gerçekle eşleştiğini doğrulamak için vardır. Her şeyi taklit ederseniz ve canlı hizmete karşı asla doğrulama yapmazsanız, üretim çökerken paketiniz yeşil kalır. Ayrım kabaca şöyledir: hız ve izolasyon için taklit edin, sözleşmeyi doğrulamak için gerçeği kullanın. Her birinin nereye uyduğuna daha derinlemesine bakmak için, API taklidinin işe yaradığı senaryoların ve taklit sunucu ile gerçek sunucu arasındaki farkın bu dökümüne bakın.
Bir bakışta beş adımlı iş akışı
Bir API'yi test için taklit etmek, dil veya çerçeveden bağımsız olarak her zaman aynı beş adımdır:
- Taklitin gerçek yanıt şeklini yansıtması için **şemayı tanımlayın**.
- Bu şemadan **taklit yanıtları** (statik veya dinamik) **oluşturun**.
- Bu yanıtları bir URL'de sunan bir **taklit sunucu çalıştırın**.
- Temel URL'yi yapılandırılabilir hale getirerek **testlerinizi taklit sunucuya yönlendirin**.
- Gerçek sunucunun isteğe bağlı olarak üretmeyeceği **hata yollarını test edin**.
Bu kılavuzun geri kalanı, her adımı somut bir örnekle ele alıyor: GET /orders/{id} uç noktasına sahip küçük bir sipariş yönetimi API'si. Bu uç noktayı sürekli bir akış olarak aklınızda tutun.
Adım 1: Şemayı tanımlayın
Bir taklit ancak gerçek yanıt şeklini yansıtıyorsa kullanışlıdır. Bir şemadan başlayın. API'nizin zaten bir OpenAPI belgesi varsa, onu kullanın. Yoksa, test edilen uç nokta için bir tane yazın. İşte GET /orders/{id} için kısaltılmış bir tanım:
paths:
/orders/{id}:
get:
parameters:
- name: id
in: path
required: true
schema: { type: string }
responses:
'200':
content:
application/json:
schema:
type: object
properties:
id: { type: string }
status: { type: string, enum: [pending, shipped, delivered] }
total: { type: number }
items: { type: array, items: { type: object } }
'404':
description: Order not found
Şema iki işlev görür. Taklitin hangi alanları döndüreceğini söyler ve size tek bir doğru kaynak sağlar. Arka uç sözleşmeyi değiştirdiğinde, şemayı güncellersiniz ve ondan türetilen her taklit doğru kalır. Şema öncelikli taklit, API sözleşme testini dürüst tutar.
Adım 2: Taklit yanıtlar oluşturun
Yanıt gövdesini üretmenin iki yolu vardır.
Statik yanıtlar sabit JSON'dur. Tam yükü bir kez yazarsınız ve taklit onu değişmeden döndürür. Tahmin edilebilirler ve karşılaştırması kolaydır, bu da onları tek bir bilinen değeri istediğiniz birim testleri için ideal kılar.
Dinamik yanıtlar istek başına oluşturulur. "total": 149.99'u sabit kodlamak yerine, taklit alanları gerçekçi oluşturulmuş değerlerle doldurur: id için bir UUID, status için rastgele bir enum üyesi, total için makul bir para miktarı. Dinamik veriler, uzun dizelerde veya beklenmedik boş alanlarda bozulan bir ayrıştırıcı gibi tek bir sabit yükün gizlediği hataları yakalar.
Çoğu ekip ikisini de kullanır. Onay ağırlıklı testler için statik yükler, fuzz tarzı kapsama için dinamik üretim. Apidog ile ikisini de elle yazmazsınız. Apidog şemayı okur ve email, phone veya avatar gibi alan adlarını doğru veri türüyle eşleştirerek bir taklit uç noktası otomatik olarak oluşturur. Bir tarayıcıyı taklit URL'sine yönlendirirsiniz ve hemen geçerli bir yanıt alırsınız.
Yükleri elle yazdığınızda, gerçekçi tutun. "total": 0 ve boş bir items dizisi olan bir test siparişi, saf bir ayrıştırıcıdan geçer ancak hataları gizler. Üretime benzeyen değerler kullanın: gerçekçi görünen bir toplam, iki veya üç satır öğesi, enumda gerçekten bulunan bir durum. Taklit verileri gerçek bir isteğin döndürdüğü şeye ne kadar yakınsa, testiniz o kadar değerlidir.
Adım 3: Taklit sunucuyu çalıştırın
Bir taklit yanıtı, bir şey onu sunana kadar işe yaramaz. İki barındırma seçeneğiniz var.
Yerel bir taklit sunucu makinenizde, genellikle localhost:4010 gibi bir bağlantı noktasında çalışır. Hızlıdır, çevrimdışı çalışır ve birim ve entegrasyon testleri için varsayılandır. Prism gibi hafif araçlar, doğrudan bir OpenAPI dosyasından bir tane başlatır:
prism mock openapi.yaml
# Mock server listening on http://127.0.0.1:4010
Bir bulut taklit sunucusunun genel bir URL'si vardır. Bir mobil uygulamanın, bir CI çalıştırıcısının veya harici bir işbirlikçinin dizüstü bilgisayarınıza erişimi olmadan taklit sunucuyu çağırması gerektiğinde buna başvurun. Apidog, her projeye barındırılan bir Bulut Taklit URL'si verir, böylece başka bir ağdaki bir ekip arkadaşı sizinle aynı uç noktaya erişebilir.
Test çalıştırmaları için yerel olanı tercih edin. Ağ gecikmesi ve paylaşılan durumu yoktur, bu nedenle iki yapı asla çarpışmaz. Demolar ve cihazlar arası testler için bulut seçeneğini kullanın.
Adım 4: Testlerinizi taklit sunucuya yönlendirin
Şimdi test kodunu üretim yerine taklit sunucuya bağlayın. En temiz yaklaşım, yapılandırılabilir bir temel URL'dir. Onu bir ortam değişkeninden okuyun, böylece aynı test dosyası yerel olarak taklit sunucuya ve bir sözleşme işinde gerçek API'ye karşı çalışır.
// orderClient.test.js
import { getOrder } from './orderClient.js';
const BASE_URL = process.env.API_BASE_URL || 'http://127.0.0.1:4010';
test('parses a shipped order', async () => {
const order = await getOrder('order_8842', BASE_URL);
expect(order.status).toBe('shipped');
expect(typeof order.total).toBe('number');
});
İstemci temel URL'yi bir argüman olarak alır; üretim kodunda taklit edildiğini bilen hiçbir şey yoktur. CI'da, paket çalışmadan önce API_BASE_URL'yi taklit sunucunun adresine ayarlarsınız. Bu desen, taklit işlemeyi tamamen uygulama mantığınızın dışında tutar, ki olması gereken yer burasıdır. Testleri bir kanal aracılığıyla çalıştırırsanız, CI/CD'de API testlerini otomatikleştirirken aynı fikir geçerlidir.
Adım 5: Hata yollarını test edin
Bu, çoğu ekibin atladığı bir adımdır ve karşılığını veren bir adımdır. Gerçek bir sunucu nadiren istediğinizde bir 500 döndürür. Bir taklit, komut üzerine bir tane döndürür.
Taklit sunucuyu belirli hata yanıtlarını sunacak şekilde yapılandırın, ardından istemcinizin her birini işlediğini doğrulayın:
| Senaryo | Taklit döndürür | Ne doğruluyorsunuz |
|---|---|---|
| Kayıp kayıt | 404 |
İstemci açık bir "bulunamadı" hatası fırlatır |
| Sunucu hatası | 500 |
İstemci yeniden dener, sonra bir geri dönüş sunar |
| Hız sınırlı | 429 ile Retry-After |
İstemci doğru miktarda geri çekilir |
| Yavaş yanıt | 5 sn gecikmeden sonra 200 |
İstemci zaman aşımına uğrar ve kurtarır |
| Yanlış biçimlendirilmiş gövde | Bozuk JSON ile 200 |
İstemci sorunsuz bir şekilde başarısız olur, çökmez |
Apidog'un gelişmiş taklit kuralları, isteğe bağlı olarak farklı yanıtlar döndürmenize olanak tanır; böylece order_404 için yapılan bir istek 404 döndürürken, diğer tüm kimlikler normal bir 200 döndürür. Bu size hem mutlu yolu hem de hataları kapsayan tek bir taklit uç noktası verir. Bunu güçlü API doğrulama ile birleştirin ve paketiniz yalnızca durum kodlarını değil, davranışı da doğrular.
Büyüyen bir test paketi genelinde taklitleri düzenleme
Tek bir taklit uç noktası kolaydır. Bir pakete yayılmış yüz tanesi, ekiplerin kontrolü kaybettiği yerdir. Birkaç alışkanlık seti yönetilebilir tutar.
Taklitleri, kullandıkları teste göre değil, temsil ettikleri gerçek hizmete göre gruplandırın. Ödeme API'si değiştiğinde, yirmi test dosyası değil, güncellenecek tek bir yer istersiniz. Taklit donanımları, order-shipped veya order-rate-limited gibi temsil ettikleri senaryoya göre adlandırın, böylece başarısız bir test açıkça okunur. Taklit tanımlarını testlerin yanında sürüm kontrolünde tutun, çünkü bir taklit testin bir parçasıdır ve aynı incelemeyi hak eder.
Her teste kendi özel yükünü verme dürtüsüne direnin. Çoğu test, bir alanı değiştirilmiş aynı gerçekçi sipariş nesnesini ister. Temel bir yanıtı bir kez tanımlayın ve yalnızca test edilen alanı geçersiz kılın. Bu, paketi okunabilir tutar ve bir sözleşme değişikliğinin dağınık kopyalar yerine tek bir temel tanımı etkilemesi anlamına gelir. API otomasyonu için bir test paketini sürdürülebilir kılan aynı disiplin, arkasındaki taklitlere de doğrudan uygulanır.
Taklitleri dürüst tutmak
Bir taklit sapar. Arka uç bir alan ekler, total'ı amount olarak yeniden adlandırır veya bir enum'u değiştirir ve taklitiniz eski şekli döndürmeye devam eder. Testler geçer; üretim başarısız olur. Bu, taklitin yanlış gitmesinin en yaygın yoludur ve sessizdir. Paketinizde hiçbir şey şikayet etmez, çünkü paket takliti kendine karşı ölçer.
İki alışkanlık bunu önler. Birincisi, takliti arka ucun yayınladığı aynı şemadan türetin, böylece bir sözleşme değişikliği ikisini aynı anda günceller. Bir OpenAPI dosyasından oluşturulan bir taklit, bu dosya değiştiğinde yeniden oluşturulur; elle yazılan bir taklit bunu yapmaz. İkincisi, gerçek API'ye karşı düzenli olarak küçük bir dizi sözleşme testi çalıştırın. Tek görevleri, canlı yanıtın hala taklitlerinizin kullandığı şemayla eşleştiğini doğrulamaktır. Bunlar başarısız olduğunda, kullanıcılar öğrenmeden önce taklitin güncel olmadığını bilirsiniz.
Kod incelemesi sırasında taklitleri gözden geçirmek de yardımcı olur. Bir çekme isteği bir API yanıtını değiştirdiğinde, gözden geçiren kişinin eşleşen taklitin de değişip değişmediğini kontrol etmesi gerekir. Takliti, tek kullanımlık bir test yardımcısı yerine sözleşmenin bir parçası olarak görmek, taklit edilmiş bir paketi aylar süren değişiklikler boyunca güvenilir tutar.
Şemayı tutan, takliti oluşturan ve ona karşı testleri çalıştıran tek bir ortam istiyorsanız, Apidog'u İndirin. Tasarımı, taklit sunucuyu ve test paketini senkronize tutar, böylece test ettiğiniz taklit her zaman mevcut sözleşmedir. Daha geniş seçenekler için, REST API taklit araçlarının bu derlemesindeki alanı karşılaştırın.
Sıkça sorulan sorular
Her test için API'yi taklit etmeli miyim?
Hayır. Kendi kodunuzu kontrol ettiğiniz birim ve entegrasyon testleri için taklit kullanın. Gerçek API'ye vuran küçük bir sözleşme ve uçtan uca test grubu bulundurun, çünkü bunlar taklitinizin hala üretimle eşleştiğini doğrular. Her şeyi taklit etmek, sözleşme sapmasını gizler.
Statik ve dinamik taklit yanıt arasındaki fark nedir?
Statik yanıt, asla değişmeyen sabit bir JSON yüküdür ve tahmin edilebilir doğrulamalar için iyidir. Dinamik yanıt, gerçekçi değerlerle istek başına oluşturulur ve tek bir sabit yükün kaçıracağı hataları yakalar. Çoğu ekip ikisini de kullanır.
Taklitimin doğru kaldığından nasıl emin olabilirim?
Takliti, arka ucun kullandığı aynı şemadan, ideal olarak bir OpenAPI belgesinden oluşturun. Ardından, canlı yanıtın hala bu şemayla eşleştiğini doğrulamak için gerçek API'ye karşı düzenli sözleşme testleri çalıştırın. Bunlar başarısız olursa, taklitinizin güncellenmesi gerekir.
Bir taklit yavaş veya başarısız yanıtları simüle edebilir mi?
Evet ve bu, taklit yapmanın en güçlü nedenlerinden biridir. Bir takliti, bir 500, bir 429 ile bir Retry-After başlığı veya gecikmeli bir 200 döndürecek şekilde yapılandırabilirsiniz. Bu, sağlıklı bir gerçek sunucunun asla isteğe bağlı olarak tetiklemeyeceği yeniden deneme mantığını ve zaman aşımlarını doğrulamanıza olanak tanır.
Test için yerel taklit sunucu mu yoksa bulut taklit sunucu mu?
Test çalıştırmaları için yerel bir taklit sunucu kullanın. Hızlıdır, ağ gecikmesi yoktur ve yapılar arasında paylaşılan durumu önler. Bir mobil cihazın, bir CI çalıştırıcının veya harici bir işbirlikçinin makinenize erişimi olmadan taklite ulaşması gerektiğinde bulut tabanlı bir taklit kullanın.