Bruno Mock Sunucuya Sahip mi? (Ve Onun Yerine Ne Kullanmalı)

Bruno hafif, Git-yerel, açık kaynaklı bir API istemcisidir ve bu tasarım onu hızlı ve sürümlemesi kolay kılar. Ancak ekiplerin hızla karşılaştığı bir boşluk bırakır: henüz var olmayan bir uç noktayı taklit etmenin (mock) bir yolu yoktur. Bir Bruno mock sunucusu alternatifi aradıysanız, bu kılavuz boşluğun neden var olduğunu, insanların kullandığı geçici çözümleri ve doğrudan OpenAPI spesifikasyonunuzdan bir mock sunucusu nasıl oluşturulacağını açıklar.

Kısa cevap baştan: Bruno'nun yerleşik bir mock sunucusu yoktur. İstek gönderebilir ve testler yazabilirsiniz, ancak örnek yanıtlar döndüren sahte bir uç nokta oluşturamazsınız. Taklit etmek (mocking) için harici bir araca başvurmanız veya kendi sunucunuzu elle oluşturmanız gerekir.

Neden bir mock sunucusuna ihtiyacınız var?

Bir mock sunucusu, henüz oluşturulmamış, kararlı olmayan veya isteğe bağlı olarak tetiklemesi zor olan uç noktalar için gerçekçi yanıtlar döndürür. Bu, birkaç şeyi mümkün kılar:

• Paralel geliştirme. Ön uç ve mobil ekipler, arka uç hala geliştirme aşamasındayken sözleşmeye göre geliştirme yapar. Kimse beklemez.
• Hata yolu testi. Gerçek API'lar, ihtiyacınız olduğunda nadiren size 429 veya 503 döndürür. Bir mock, isteğe bağlı olarak herhangi bir durumu, başlığı veya hatalı biçimlendirilmiş gövdeyi döndürür.
• Demolar ve prototipler. Canlı bir arka uç, veritabanı veya kimlik bilgileri olmadan çalışan bir akışı gösterin.
• Kararlı CI. Bir mock'u vuran testler, bir hazırlık sunucusunun kapalı olması veya hız sınırlamasına tabi olması nedeniyle bozulmaz.

Bir mock'un kasıtlı olarak test etmenize yardımcı olduğu, üretimde gerçekleşmesini beklemek yerine, hata senaryoları şunlardır:

Bruno'nun bir mock sunucusu var mı?

Hayır. Bruno, istek göndermeye, koleksiyonları düz dosyalar olarak düzenlemeye ve onaylamalar çalıştırmaya odaklanır. Yerel bir mock sunucusu yoktur ve kaydedilmiş bir isteği canlı bir stuba dönüştüren bir ayar da yoktur. Bu, bilinçli bir kapsam seçimidir, bir ihmal değil, ancak bu, mocking'in aracın dışında yaşadığı anlamına gelir.

Uygulamada, Bruno kullanıcıları bu boşluğu iki şekilde kapatır:

1. Harici mocking araçları. Mockoon, WireMock, Prism veya json-server gibi ayrı bir hizmet kurun, yanıtları orada tanımlayın ve ardından Bruno'yu o URL'ye yönlendirin. İki araç, iki doğruluk kaynağı.
2. Elle oluşturulan sunucular. Önceden tanımlanmış JSON döndüren küçük bir Express, Flask veya FastAPI uygulaması yazın. Tek bir uç nokta için hızlıdır, büyüyen bir API'da bakımı yorucudur.

Her ikisi de işe yarar. Her ikisi de koleksiyonunuzun dışında yaşayan hareketli parçalar ekler.

Eklemeli (bolt-on) mocking'in maliyeti

Bruno'ya ayrı bir mock katmanı eklemek işe yarar, ancak maliyeti zamanla ortaya çıkar:

• Kayma. Spesifikasyonunuz, Bruno istekleriniz ve mock tanımlarınız üç farklı yerde bulunur. Bir uç noktayı değiştirdiğinizde üçünü de güncellersiniz veya biri sessizce eskimeye başlar.
• Kurulum yükü. Her yeni ekip üyesi, yerel olarak herhangi bir şey çalıştırmadan önce mock aracını kurar ve yapılandırır.
• Manuel yanıt yazma. Elle oluşturulan sunucular, her alan ve her durum kodu için örnek yükleri elle yazmak anlamına gelir.
• Gerçekçi veri yok. Statik stublar her zaman aynı "name": "string" değerini döndürür, bu da yalnızca çeşitli girdilerle ortaya çıkan hataları gizler.

Bunların hiçbiri ölümcül değil. Ancak API büyüdükçe artan bir sürtünmedir. Bu boşlukların nerede biriktiğine dair daha kapsamlı bir bakış için, Bruno alternatif hepsi bir arada API platformu analizimize bakın.

Bunun yerine OpenAPI spesifikasyonunuzdan bir mock sunucusu oluşturun

Daha temiz yol, mock'u zaten sürdürdüğünüz sözleşmeden türetmektir. Apidog bunu yapar: bir OpenAPI spesifikasyonunu içe aktarın veya yazın; bu, tasarım, test ve dokümanlar için kullandığınız aynı tanımlardan çalışan bir mock sunucusu oluşturur. Üç değil, tek bir doğruluk kaynağı.

Birkaç şey bunu eklemeli araçlardan farklı kılar:

• Spesifikasyondan akıllı mock. Apidog, alan adlarını ve türlerini okur ve olası verileri döndürür, böylece bir email alanı e-posta gibi ve bir created_at alanı bir tarih gibi görünür, yazılacak kural olmadan.
• Dinamik yanıtlar. Yanıtlar her istekte şemanızdan oluşturulur, böylece donmuş bir örnek yerine çeşitli veriler elde edersiniz. Belirli bir duruma ihtiyacınız olduğunda koşullu kurallar ekleyebilirsiniz.
• Kodsuz kurulum. Ayrı bir sunucu yazmaz veya barındırmazsınız. Uç noktayı spesifikasyonda tanımlayın ve mock URL'si hazırdır.
• Senkronize kalır. Spesifikasyonu güncellediğinizde mock da güncellenir, çünkü tek bir tanımı paylaşırlar.

Mock, istek kütüphanesi ve dokümantasyon aynı projeden geldiği için hizalı kalması gereken üçüncü bir yer yoktur. İş akışınız Git odaklıysa, spesifikasyon da karşılaştırılabilir ve incelenebilir kalır, bu da Git-yerel bir API iş akışıyla iyi bir uyum sağlar. Mocking'in nerede işe yaradığı hakkında daha fazla bilgi için API mocking kullanım durumları bölümüne bakın.

Hızlı nasıl yapılır: spesifikasyondan mock URL'sine

Mevcut bir spesifikasyondan bir mock'u ayağa kaldırmanın kısa versiyonu şöyledir:

1. Spesifikasyonunuzu içe aktarın. OpenAPI (veya Swagger) dosyanızı getirin veya Apidog'u spesifikasyon URL'sine yönlendirin. Mevcut uç noktalar ve şemalar olduğu gibi gelir.
2. Bir uç nokta açın. İçe aktarılan her uç noktanın zaten kendi şeması vardır, bu nedenle mock'un ihtiyacı olan her şeye sahiptir.
3. Mock URL'sini alın. Apidog, yerel ve bulut mock uç noktalarını otomatik olarak sunar. Dağıtılacak sunucu yok.
4. İstek gönderin. Mock URL'sine istek gönderin ve spesifikasyondan oluşturulmuş, şema şekilli JSON geri alırsınız.
5. Yanıtları ayarlayın (isteğe bağlı). Belirli bir yolu test etmeniz gerektiğinde, belirli durum kodları veya uç durumlar için, örneğin 429 gibi kurallar ekleyin.

Ön uçunuzu, mobil derlemenizi veya test takımınızı mock URL'sine yönlendirir ve arka uç yetişirken çalışmaya devam edersiniz.

Geçici çözümlerin yeterli olduğu zamanlar

Adil olmak gerekirse, her zaman spesifikasyon odaklı bir mock'a ihtiyacınız yoktur. Bruno'yu hafif bir harici araçla birlikte kullanmaya devam edin:

• Hızlı bir yerel test için sadece bir veya iki uç noktayı taklit etmeniz gerektiğinde.
• Ekibiniz Bruno'nun dosya tabanlı koleksiyonlarını sürdürmekten memnun ve araç değiştirmek istemiyorsa.
• Çeşitli verileri veya birçok hata yolunu test etmediğiniz için statik bir stub yeterlidir.
• Zaten Mockoon, WireMock veya Prism kullanıyorsunuz ve ek doğruluk kaynağı sizi yavaşlatmıyorsa.

Takas gerçektir: hafif yol Bruno'nun basitliğini korur ancak mock'ları ayrı ayrı sürdürmenize neden olur. Spesifikasyon odaklı yol, daha geniş bir platform benimseme maliyetiyle bu kaymayı ortadan kaldırır. API'nizin ne kadar büyüdüğüne göre seçim yapın.

SSS

Bruno'nun yerleşik bir mock sunucusu var mı?

Hayır. Bruno, istek göndermek ve test çalıştırmak için bir API istemcisidir. Yerel bir mock sunucusu yoktur, bu nedenle uç noktaları taklit etmek için harici bir araç kullanmanız veya kendi stub sunucunuzu yazıp Bruno'yu ona yönlendirmeniz gerekir.

Bruno tarzı bir iş akışına mocking eklemenin en kolay yolu nedir?

Mock'u ayrı ayrı tanımlamak yerine OpenAPI spesifikasyonunuzdan oluşturun. Apidog gibi araçlar spesifikasyonu okur ve hazır bir mock URL'si üretir, böylece tasarım, mocking, test ve dokümanlar arasında tek bir doğruluk kaynağı tutar, mock tanımlarını ikinci bir yerde sürdürmek zorunda kalmazsınız.

Bruno'yu kullanmaya devam edip yanına bir mock sunucusu ekleyebilir miyim?

Evet. Mockoon, WireMock veya Prism gibi harici bir mock aracı çalıştırın, yanıtları orada tanımlayın ve Bruno'yu o URL'ye yönlendirin. Bu işe yarar, ancak spesifikasyonunuz, istekleriniz ve mock verileriniz ayrı yerlerde bulunur ve kaymalar olabilir, ki bu da ekiplerin birleşmesinin ana nedenidir.

Ayrı bir mock katmanını sürdürmek, kazandırdığından daha pahalı hale gelmeye başladıysa, spesifikasyon odaklı bir mock denemeye değerdir. OpenAPI dosyanızı Apidog'a aktarın ve birkaç dakika içinde çalışan bir mock URL'sine sahip olursunuz, barındırılacak fazladan bir sunucuya gerek kalmaz.