Çoğu ekip bir API'yi nasıl taklit edeceğini bilir. Daha az ekip ise bunun ne zaman gerçekten yardımcı olduğuna ve ne zaman sadece bakımı gereken ek bir katman oluşturduğuna dair net bir cevaba sahiptir. Doğru zamanda başvurduğunuz bir taklit, gerçek bir darboğazı ortadan kaldırır. Alışkanlıktan yarattığınız bir taklit ise gerçeklikten uzaklaşan ve size sessizce yalan söyleyen başka bir şeye dönüşür.
Bu makale "nasıl" kısmını atlıyor ve "ne zaman" kısmına odaklanıyor. Her bölüm, taklit etmenin kendini kanıtladığı somut bir durumu ele alıyor: tamamlanmamış bir arka uçta geliştirme yapmak, hata yollarını test etmek, kararsız bir üçüncü taraf hizmetinin yerine geçmek, demoları çalıştırmak ve CI'ı stabilize etmek. Bunu bir karar destek aracı olarak okuyun, bir eğitim olarak değil.
Paralel ön uç ve arka uç geliştirme
Bu klasik bir durumdur. Ön uç ekibinin, arka uç ekibinin henüz oluşturmadığı bir uç noktaya ihtiyacı vardır. Bir taklit olmadan, ön uç ya bekler ya da gerçek hizmetle ilk temasında bozulan tahminlere göre kod yazar.
Bir taklit, bağımlılığı ortadan kaldırır. Her iki ekip de genellikle bir OpenAPI belgesi olarak sözleşme üzerinde anlaşır. Ön uç, bu sözleşmeden üretilen bir taklide göre geliştirme yaparken, arka uç gerçek şeyi uygular. Arka uç kullanıma sunulduğunda, ön uç temel URL'yi değiştirir ve her iki taraf da sözleşmeye uyduysa, başka hiçbir şey değişmez.
Anlaşma, yük taşıyan kısımdır. Yalnızca ön uç tarafından icat edilen bir taklit, yalnızca bir ekibin varsayımlarını kodlar. Ortak bir spesifikasyondan türetilen bir taklit, her iki ekibi de hizalı tutar; bu da API sözleşme testinin arkasındaki aynı prensiptir. Paralel çalışmayı engellememek için taklit kullanın, ancak yalnızca her iki tarafın da onayladığı bir sözleşmeye karşı.
Getirisi bir proje boyunca katlanır. Arka uçta asla bloke olmayan bir ön uç ekibi, özellikleri kendi programına göre yayınlar. Yarım kalmış uç noktalar için dürtülmeyen bir arka uç ekibi odaklanmış kalır. Tasarımcılar ve ürün yöneticileri, haftalar öncesinden tepki verebilecekleri tıklanabilir bir yapıya sahip olurlar. Bunların hiçbiri gerçek hizmetin henüz var olmasını gerektirmez. Tek devam eden maliyet, sözleşme geliştikçe taklidi sözleşmeyle uyumlu tutmaktır ki bu da taklit elle yazmak yerine spesifikasyondan üretildiğinde ucuzdur.
İsteğe bağlı olarak tetikleyemeyeceğiniz hata yollarını test etme
Sağlıklı bir API 200 döner. Sorun da budur. İstemci kodunuzun ayrıca 429, 500, 503, hatalı gövdeleri ve zaman aşımlarını ele alması gerekir ve çalışan bir sunucu, testiniz istediğinde bunları üretmeyecektir.
Bir taklit bunları komutla üretir. Onu bir istek için 500, bir diğeri için Retry-After başlığıyla 429 ve üçüncü bir istek için kasıtlı bir gecikmeden sonra gelen bir gövde döndürecek şekilde yapılandırırsınız. Ardından yeniden deneme mantığınızın, geri çekilmenizin ve zaman aşımı yönetiminizin hepsinin doğru davrandığını iddia edersiniz.
| Test Edilemeyen Hata | Taklit 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 |
Bu, ekiplerin en sık atladığı ve en çok pişmanlık duyduğu kullanım durumudur. Hiç uygulanmamış hata yönetimi, sahip olmadığınız hata yönetimidir. Her hata yolunun varsayılmak yerine doğrulanması için taklidi kapsamlı API doğrulama testleriyle eşleştirin.
Taklit etmeye değer ikinci bir hata türü vardır: geçerli HTTP olan ancak alan adınız için yanlış olan yanıtlar. Negatif fiyatlı bir 200, enum'unuzda olmayan bir duruma sahip bir sipariş, next imleci hiçbir yere işaret etmeyen sayfalandırılmış bir liste. Gerçek bir sunucu, doğruysa, bunları asla göndermez. Bir taklit gönderebilir ve istemcinize kasten bozuk ama iyi biçimlendirilmiş veri beslemek, ayrıştırma kodunuzun sessizce yaptığı varsayımları nasıl bulduğunuzdur.
Üçüncü taraf bir API'nin yerini almak
Testlerinizin içinde gerçek bir ödeme işlemcisini, haritalama hizmetini veya kargo API'sini çağırmak yavaştır, bazen çağrı başına para maliyeti vardır ve kontrol edemediğiniz bir hizmete bağlıdır. Kum havuzları kapalıysa, test paketiniz de kapalıdır.
Üçüncü tarafı taklit edin. Gerçek yanıtlarını bir kez kaydedersiniz veya yayınlanmış şemasından taklitler oluşturursunuz, ardından testlerinizi taklide karşı çalıştırırsınız. Testler hızlı, ücretsiz ve deterministik hale gelir. Satıcı bir kesinti yaşadığında da çalışmaya devam ederler.
Bir bakım maliyeti vardır. Üçüncü taraf size bildirmeden API'sini değiştirebilir ve taklidiniz bunu bilmez. Çözüm, gerçek hizmeti çağıran ve yanıtın hala taklidinizin şekliyle eşleştiğini doğrulayan küçük, zamanlanmış bir iş çalıştırmaktır. Bu sözleşme kontrolü, canlı üçüncü tarafa dokunduğunuz tek yerdir ve kullanıcılarınızdan önce sapmaları yakalar. Ayrıca, planlı bir değişiklik size başarısız bir sözleşme testinden önce ulaşması için satıcının değişiklik günlüğüne abone olmak da değerlidir.
Demoları ve prototipleri güçlendirme
Müşteri önünde canlı hizmetleri çağıran bir demo bir kumardır. Yavaş bir sorgu, boş bir sonuç kümesi veya talihsiz bir kesinti, cilalı bir sunumu bir özüre dönüştürür.
Bir taklit, demoyu deterministik yapar. Demoya tam olarak ihtiyacı olan veriyi kodlarsınız: zamanında gönderilen sipariş, sağlıklı rakamlarla dolu kontrol paneli, temiz sonuçlar döndüren arama. Aynısı prototipler için de geçerlidir. Herhangi bir arka uç var olmadan çok önce bir UI akışını doğrulayabilir veya bir özelliği tanıtabilirsiniz, çünkü taklit prototipin beklediği her yanıtı sağlar.
Buradaki amaç test etmek değil, kontrol etmektir. İzleyicinin ne göreceğine siz karar verirsiniz ve hiçbir dış etken bunu bozamaz. Erken aşama çalışmalar için, bir taklit genellikle insanlara tıklanabilir bir şey sunmanın en hızlı yoludur. Bu kategorideki araçların karşılaştırması çevrimiçi API taklit araçları incelemesinde ele alınmıştır.
Bir prototip taklidi aynı zamanda bir tasarım belgesi işlevi de görür. Taklit, nihai API'nin sunacağı tam şekilleri döndürdüğünde, buna karşı yazdığınız ön uç kodu gerçek koddur, tek kullanımlık iskele değildir. Arka uç daha sonra aynı sözleşmeyi yerine getirirse, prototip sadece temel URL değişikliğiyle ürüne dönüşür. Bir taklidin bir destek olarak kullanılması ile bir başlangıç avantajı olarak kullanılması arasındaki fark budur.
CI'ı hızlı ve kararlı tutmak
CI'da harici hizmetleri çağıran bir test paketi, bu hizmetlerin her sorununu miras alır. Ağ aksaklıkları, oran sınırlamaları, başka bir derlemenin yeni değiştirdiği paylaşılan hazırlık verileri: her biri incelenen kodla hiçbir ilgisi olmayan kararsız bir hataya dönüşür.
Kararsız testler, insanları hataları görmezden gelmeye alıştırır, bu da CI'ın amacını boşa çıkarır. Harici bağımlılıkları taklit etmek, paketi hermetik hale getirir. Her çalıştırma aynı bilinen durumdan başlar, ağ gidiş-dönüşü olmadığı için daha hızlı biter ve yalnızca kod gerçekten bozuk olduğunda başarısız olur.
Bir istisna tutun. Gerçek API'ye karşı, commit başına test paketinden ayrı olarak, zamanlanmış bir şekilde ince bir sözleşme testi katmanı çalıştırın. Bunlar, taklitlerin hala üretimle eşleştiğini doğrular. Commit başına paket hızlı ve taklit edilmiş kalır; zamanlanmış iş sapmayı yakalar. Bu ayrım, sağlıklı bir CI/CD test hattı için merkezidir.
Hız kazanımı küçük bir kolaylık değildir. On iki dakikadan doksan saniyeye düşen bir test paketi, bir ekibin çalışma şeklini değiştirir. Geliştiriciler umut etmek yerine her commit'ten önce çalıştırır. İnceleyiciler, farkı okumak için gereken sürede sonuçları görür. Hızlı, hermetik bir test paketi, insanların gerçekten güvendiği bir şeydir ve güven, otomatik testin yatırım getirisinin tamamıdır.
Ne zaman taklit edilmemeli
Taklit etmenin bir hata modu vardır: artık gerçeklikle uyuşmayan bir taklit. Testler yeşil kalırken üretim bozulur, çünkü onlar bir kurguyu doğrularlar.
Test edilen şeyin entegrasyonun kendisi olduğu durumlarda taklit etmeyin. Sözleşme testleri ve uçtan uca kontroller, gerçek sınırı doğrulamak için vardır, bu yüzden onları taklit etmek varlık nedenlerini ortadan kaldırır. Gerçek şeye karşı asla doğrulamadığınız bir bağımlılığı taklit etmeyin, çünkü doğrulanmamış bir taklit sapacaktır. Ve gerçek hizmet test ortamınızda hızlı, ücretsiz ve güvenilir olduğunda bir taklide başvurmayın; taklit sadece ek bir yük olur.
Genel kural: hız, izolasyon ve kontrol için taklit edin ve taklitlerin hala doğru olduğunu doğrulamak için gerçekliğe dokunan küçük, dürüst bir test kümesi tutun. Taklidin ve sözleşme kontrolünün tek bir yerde olmasını istiyorsanız, Apidog API tasarımınızdan taklitler oluşturur ve hem taklide hem de canlı uç noktaya karşı testler çalıştırır. Bunu kurmak için Apidog'u indirin ve mevcut spesifikasyonunuzdan başlayın. Kavramsal temel için, taklit bir API'nin aslında ne olduğunu görün.
Sıkça sorulan sorular
Gerçek API'yi çağırmak yerine ne zaman bir API'yi taklit etmeliyim?
Hız, izolasyon veya kontrole ihtiyacınız olduğunda taklit edin: tamamlanmamış bir arka uca karşı paralel geliştirme, gerçek bir sunucunun üretmeyeceği hata yollarını test etme, yavaş veya ücretli bir üçüncü taraf hizmetinin yerine geçme, demoları çalıştırma ve CI'ı kararlı tutma. Sözleşme ve uçtan uca testler için gerçek API'yi çağırın.
Taklit etme, entegrasyon testinin yerini alır mı?
Hayır. Taklit etme, kendi kodunuzu kontrol ettiğiniz birim ve bileşen testleri içindir. Entegrasyon ve sözleşme testleri, asıl hizmetin sözleşmeyle eşleştiğini doğrulamakla görevli olduklarından, gerçek sınıra isabet etmelidir. Bunları taklit etmek, amaçlarını ortadan kaldırır.
Bir taklidin güncelliğini kaybetmesini nasıl önlerim?
Taklidi, ideal olarak OpenAPI gibi paylaşılan bir şemadan oluşturun, böylece bir sözleşme değişikliği onu günceller. Ardından, canlı yanıtın hala o şemayla eşleştiğini doğrulamak için gerçek API'ye karşı zamanlanmış sözleşme testleri çalıştırın. Sapma, kullanıcılara ulaşmadan önce yakalanır.
Kontrol etmediğim bir üçüncü taraf API'yi taklit edebilir miyim?
Evet, ve en güçlü kullanım durumlarından biridir. Üçüncü tarafın gerçek yanıtlarını kaydedin veya yayınlanmış şemasından taklitler oluşturun, ardından hız ve güvenilirlik için taklide karşı test edin. Satıcı API'sini değiştirdiğinde fark etmeniz için canlı hizmete karşı zamanlanmış bir kontrol ekleyin.
Taklit etme, demolar ve prototipler için faydalı mıdır?
Çok. Bir taklit, demoyu, izleyicinin görmesini istediğiniz veriyi tam olarak kodlayarak, canlı bir kesinti veya talihsiz veriden kaynaklanan herhangi bir risk olmadan deterministik hale getirir. Prototiplemeler için bir taklit, herhangi bir arka uç var olmadan önce bir kullanıcı arayüzü akışını oluşturmanıza ve doğrulamanıza olanak tanır.