DEV Community

Cover image for Bruno Mock Sunucuya Sahip mi? (Ve Onun Yerine Ne Kullanmalı)
Tobias Hoffmann
Tobias Hoffmann

Posted on • Originally published at apidog.com

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

Bruno hafif, Git-yerel ve açık kaynaklı bir API istemcisidir. İstek göndermek, koleksiyonları düz dosyalarla yönetmek ve test yazmak için hızlıdır; ancak yerleşik bir mock sunucusu yoktur. Bu yazıda Bruno ile mocking boşluğunun neden oluştuğunu, geçici çözümleri ve OpenAPI spesifikasyonunuzdan nasıl çalışan bir mock URL’si üretebileceğinizi adım adım göreceksiniz.

Apidog'u bugün deneyin

Kısa cevap: Bruno doğrudan örnek yanıtlar döndüren sahte bir uç nokta oluşturmaz. Bruno ile isteği mock bir servise gönderebilirsiniz, ancak mock sunucusunu Bruno dışında kurmanız gerekir.

Neden bir mock sunucusuna ihtiyacınız var?

Bir mock sunucusu, henüz geliştirilmemiş, kararsız veya test ortamında tetiklemesi zor olan API uç noktaları için kontrollü yanıtlar döndürür.

Pratikte şu durumlarda işe yarar:

  • Paralel geliştirme: Ön uç veya mobil ekip, arka uç tamamlanmadan sözleşmeye göre geliştirme yapabilir.
  • Hata yolu testi: 429, 500, 503 gibi durumları bilinçli olarak test edebilirsiniz.
  • Demo ve prototip: Canlı veritabanı, kimlik bilgisi veya çalışan backend olmadan uçtan uca akış gösterebilirsiniz.
  • Kararlı CI: Testleriniz staging ortamının kapalı olmasına veya rate limit’e takılmasına bağlı olarak kırılmaz.

Örneğin aşağıdaki senaryoları gerçek sistemde beklemek yerine mock ile doğrudan üretebilirsiniz:

Senaryo Mock'un döndürdüğü Aksi takdirde neden zor?
Hız sınırı aşıldı 429 + Retry-After başlığı Arka uç isteğe bağlı olarak nadiren kısıtlama yapar
Sunucu kesintisi 500 / 503 Sadece test etmek için hazırlık ortamını bozamazsınız
Yavaş yanıt Gecikmeli gövde Gerçek gecikmeyi yeniden üretmek zor
Boş sonuç kümesi 200 ile [] Belirli veri durumuna bağlıdır
Hatalı biçimlendirilmiş yük Zorunlu bir alan eksik olan gövde Arka uç doğrulaması genellikle bunu önler

Bruno'nun bir mock sunucusu var mı?

Hayır. Bruno; istek göndermeye, koleksiyonları düz dosyalar olarak düzenlemeye ve assertion/test çalıştırmaya odaklanır. Yerel bir mock sunucusu sunmaz ve kaydedilmiş bir isteği canlı bir stub endpoint’e dönüştüren bir ayarı yoktur.

Bu nedenle Bruno kullanan ekipler genellikle iki yoldan birini seçer:

  1. Harici mocking aracı kullanmak

    • Mockoon, WireMock, Prism veya json-server gibi ayrı bir servis kurarsınız.
    • Yanıtları bu araçta tanımlarsınız.
    • Bruno isteklerini bu mock URL’sine yönlendirirsiniz.

  2. Kendi stub sunucunuzu yazmak

    • Express, Flask veya FastAPI ile küçük bir servis oluşturursunuz.
    • Belirli endpoint’ler için sabit JSON yanıtları döndürürsünüz.
    • Bruno’dan bu servise istek atarsınız.

Örneğin basit bir Express stub’ı şöyle görünebilir:

import express from "express";

const app = express();

app.get("/users/:id", (req, res) => {
  res.json({
    id: req.params.id,
    name: "Ayşe Yılmaz",
    email: "ayse@example.com"
  });
});

app.get("/rate-limit", (req, res) => {
  res.set("Retry-After", "60");
  res.status(429).json({
    error: "Too many requests"
  });
});

app.listen(3000, () => {
  console.log("Mock server running on http://localhost:3000");
});
Enter fullscreen mode Exit fullscreen mode

Bu yaklaşım küçük senaryolar için yeterlidir. Ancak API büyüdükçe mock yanıtlarını elle güncel tutmak zorlaşır.

Eklemeli mocking'in maliyeti

Bruno’nun yanına ayrı bir mock katmanı eklemek çalışır; ancak zamanla şu maliyetleri doğurur:

  • Kayma: OpenAPI spesifikasyonunuz, Bruno koleksiyonunuz ve mock tanımlarınız farklı yerlerde yaşar.
  • Kurulum yükü: Yeni ekip üyeleri Bruno dışında mock aracını da kurup yapılandırmak zorunda kalır.
  • Manuel yanıt yazma: Her endpoint, durum kodu ve response body için örnek veri elle hazırlanır.
  • Statik veri: Mock yanıtları sürekli aynı değerleri döndürürse, farklı veri kombinasyonlarında çıkacak hatalar gizlenebilir.

Örneğin bir endpoint değiştiğinde şu üç yeri güncellemeniz gerekebilir:

OpenAPI spec      -> /users/{id} response schema değişti
Bruno request     -> request/response beklentisi değişti
Mock server       -> örnek JSON hâlâ eski alanları döndürüyor
Enter fullscreen mode Exit fullscreen mode

Bu senkronizasyon problemi küçük projelerde yönetilebilir. Fakat endpoint sayısı arttıkça gerçek sürtünme yaratır.

Bu boşlukların nerede biriktiğine dair daha kapsamlı bir değerlendirme için Bruno alternatif hepsi bir arada API platformu analizine bakabilirsiniz.

Bunun yerine OpenAPI spesifikasyonunuzdan bir mock sunucusu oluşturun

Daha sürdürülebilir yaklaşım, mock’u zaten tuttuğunuz API sözleşmesinden üretmektir.

Apidog, OpenAPI spesifikasyonunuzu içe aktararak aynı tanımlardan çalışan mock endpoint’leri oluşturur. Böylece tasarım, test, dokümantasyon ve mocking için ayrı ayrı doğruluk kaynakları tutmanız gerekmez.

Bu yaklaşımın pratik farkları:

  • Spesifikasyondan mock üretimi: Endpoint, schema, field type ve response yapısı OpenAPI tanımından okunur.
  • Daha gerçekçi veri: email, created_at, id gibi alanlar şemaya uygun örnek değerlerle dönebilir.
  • Kodsuz kurulum: Ayrı Express/FastAPI stub sunucusu yazmanız gerekmez.
  • Senkronizasyon: Spesifikasyon güncellendiğinde mock da aynı kaynaktan beslendiği için kayma azalır.
  • Koşullu yanıtlar: Belirli hata senaryoları için özel status code veya response kuralı ekleyebilirsiniz.

Mock, istek kütüphanesi ve dokümantasyon aynı projeden geldiğinde hizalı kalması gereken üçüncü bir yer azalır. Git odaklı çalışıyorsanız, spesifikasyonun incelenebilir ve karşılaştırılabilir kalması Git-yerel bir API iş akışıyla da uyumludur.

Mocking’in nerelerde değer kattığını daha detaylı görmek için API mocking kullanım durumları yazısına bakabilirsiniz.

Hızlı nasıl yapılır: OpenAPI spesifikasyonundan mock URL’sine

Mevcut bir OpenAPI veya Swagger dosyanız varsa süreç şu şekilde ilerler:

1. Spesifikasyonunuzu içe aktarın

OpenAPI dosyanızı içe aktarın veya spesifikasyon URL’nizi kullanın.

Örnek basit OpenAPI şeması:

openapi: 3.0.0
info:
  title: Users API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Kullanıcı detayını getir
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Kullanıcı bulundu
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: string
                  name:
                    type: string
                  email:
                    type: string
                    format: email
                  created_at:
                    type: string
                    format: date-time
Enter fullscreen mode Exit fullscreen mode

Bu tanım mock için yeterli temel bilgileri sağlar:

  • Endpoint path’i
  • HTTP metodu
  • Path parametresi
  • Response status code
  • JSON response şeması

2. Endpoint’i açın

İçe aktarılan endpoint’i Apidog içinde açın. Endpoint’in request ve response şemaları spesifikasyondan gelir.

Bu aşamada manuel olarak JSON yazmanız gerekmez; mock response şemaya göre üretilebilir.

3. Mock URL’sini alın

Apidog, endpoint için mock URL sağlar. Bu URL’yi frontend, mobil uygulama veya test ortamınızda base URL olarak kullanabilirsiniz.

Örnek yapı:

https://mock.example.com/project-id/users/123
Enter fullscreen mode Exit fullscreen mode

Gerçek backend hazır değilken uygulamanız bu mock URL’ye istek atabilir.

4. İstek gönderin

Frontend tarafında örnek kullanım:

const response = await fetch("https://mock.example.com/project-id/users/123");
const user = await response.json();

console.log(user);
Enter fullscreen mode Exit fullscreen mode

Beklenen mock yanıt şemaya uygun şekilde döner:

{
  "id": "123",
  "name": "Ayşe Yılmaz",
  "email": "ayse.yilmaz@example.com",
  "created_at": "2026-06-02T10:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

5. Hata senaryoları ekleyin

Belirli bir yolu test etmeniz gerektiğinde mock yanıtını özelleştirin.

Örneğin rate limit senaryosu:

{
  "error": "Too many requests",
  "message": "Lütfen tekrar denemeden önce bekleyin."
}
Enter fullscreen mode Exit fullscreen mode

Status code:

429
Enter fullscreen mode Exit fullscreen mode

Header:

Retry-After: 60
Enter fullscreen mode Exit fullscreen mode

Bu şekilde frontend tarafında hata yönetimini gerçek backend’i zorlamadan test edebilirsiniz.

Bruno ile mock URL’sini nasıl kullanırsınız?

Bruno’da mock URL’yi normal bir API base URL gibi kullanabilirsiniz.

Örnek environment değişkeni:

baseUrl=https://mock.example.com/project-id
Enter fullscreen mode Exit fullscreen mode

İstek URL’si:

{{baseUrl}}/users/123
Enter fullscreen mode Exit fullscreen mode

Ardından Bruno’da normal şekilde isteği çalıştırırsınız. Eğer aynı request’i daha sonra gerçek backend’e yönlendirmek isterseniz sadece baseUrl değerini değiştirirsiniz:

baseUrl=https://api.example.com
Enter fullscreen mode Exit fullscreen mode

Bu yöntem, Bruno koleksiyonunuzu korurken mock katmanını OpenAPI sözleşmesinden üretmenizi sağlar.

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

Her projede spesifikasyon odaklı mock şart değildir. Bruno’yu harici bir araçla kullanmak şu durumlarda yeterli olabilir:

  • Sadece bir veya iki endpoint’i hızlıca mock’lamanız gerekiyorsa.
  • Statik JSON yanıtı işinizi görüyorsa.
  • Ekibiniz zaten Mockoon, WireMock veya Prism kullanıyorsa.
  • API küçükse ve mock tanımlarını elle güncel tutmak problem yaratmıyorsa.
  • Bruno’nun dosya tabanlı koleksiyon yapısını değiştirmek istemiyorsanız.

Buradaki temel takas şudur:

Harici mock aracı:
+ Basit başlangıç
+ Bruno iş akışı korunur
- Ayrı doğruluk kaynağı
- Elle güncelleme gerekir

OpenAPI tabanlı mock:
+ Tek sözleşmeden üretim
+ Daha az kayma
+ Daha ölçeklenebilir
- Daha geniş bir platform iş akışı benimsenir
Enter fullscreen mode Exit fullscreen mode

API’niz büyüdükçe ve ekip sayısı arttıkça, ikinci yaklaşım genellikle daha az bakım yükü oluşturur.

SSS

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

Hayır. Bruno, istek göndermek ve test çalıştırmak için kullanılan bir API istemcisidir. Yerel bir mock sunucusu yoktur. Endpoint’leri mock’lamak için harici bir araç kullanmanız veya kendi stub sunucunuzu yazmanız gerekir.

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

Mock yanıtlarını ayrı bir yerde elle tanımlamak yerine OpenAPI spesifikasyonunuzdan üretin. Apidog gibi araçlar spesifikasyonu okuyup hazır mock URL’si oluşturabilir. Böylece tasarım, mocking, test ve dokümantasyon aynı sözleşmeye bağlı kalır.

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

Evet. Mockoon, WireMock veya Prism gibi harici bir mock aracı çalıştırabilir, yanıtları orada tanımlayabilir ve Bruno isteklerini bu URL’ye yönlendirebilirsiniz. Bu yöntem çalışır; ancak spesifikasyonunuz, Bruno istekleriniz ve mock verileriniz ayrı yerlerde tutulduğu için zamanla kayma oluşabilir.

Mock sunucusu CI testlerinde kullanılabilir mi?

Evet. Testleriniz staging veya production benzeri ortamlara bağımlı olmak yerine mock URL’ye istek atabilir. Bu, özellikle hata senaryolarını ve edge case’leri kararlı şekilde test etmek için yararlıdır.

OpenAPI spesifikasyonum yoksa ne yapmalıyım?

Önce küçük bir OpenAPI tanımıyla başlayabilirsiniz. Kritik endpoint’leri, request parametrelerini ve response şemalarını tanımladıktan sonra mock üretmek daha kolay hale gelir. Tüm API’yi bir anda modellemek zorunda değilsiniz.

Sonuç

Bruno hızlı ve sade bir API istemcisidir; ancak yerleşik mock sunucusu sunmaz. Küçük projelerde harici bir mock aracı veya basit bir stub sunucusu yeterli olabilir.

Ancak mock yanıtlarını, API sözleşmesini ve test beklentilerini ayrı ayrı güncel tutmak pahalı hale geliyorsa, mock’u OpenAPI spesifikasyonundan üretmek daha sürdürülebilir bir yaklaşımdır.

Ayrı bir mock katmanını sürdürmek kazandırdığından daha pahalı hale geldiyse, OpenAPI dosyanızı Apidog'a aktararak kısa sürede çalışan bir mock URL’si oluşturabilirsiniz.

Top comments (0)