Otomatik API Testleri için 12 CI/CD En İyi Uygulaması

Bozuk bir API'yi gönderen yeşil bir pipeline, hiç pipeline olmamasından daha kötüdür. Müşteri bir destek talebi açana kadar ekibinize her şeyin yolunda olduğunu söyler. CI'daki çoğu API test kurulumu güçlü başlar ve sessizce çürür: birkaç uç nokta kapsanır, sonra süit değişken hale gelir, biri gürültüyü durdurmak için continue-on-error ekler ve bir çeyrek içinde testler çalışır ama kimse onlara güvenmez. Pipeline yeşildir çünkü hatayı göz ardı etmeyi öğrenmiştir.

Çözüm daha fazla test değildir. Gerçek dünya baskısı altında, Cuma öğleden sonra acil bir düzeltme veya üç servis derinliğindeki bir şema değişikliğinden kaynaklanan türden, bu testleri nasıl tasarlayacağınız, çalıştıracağınız ve geçit koyacağınız hakkında bir dizi karardır. Bu rehber, GitHub Actions, GitLab CI veya zaten kullandığınız herhangi bir çalıştırıcıya kopyalayabileceğiniz somut konfigürasyonlarla birlikte bu kararlardan on ikisini ele alıyor.

Hepsinin ortak noktası aynıdır: API testleriniz API sözleşmenizin yanında yaşamalı, tek bir taşınabilir komutla çalıştırılmalı ve sözleşme bozulduğunda yüksek sesle başarısız olmalıdır. Bu, API'yi tasarladığınız, görsel olarak doğrulama ifadeleri yazdığınız ve Apidog CLI aracılığıyla CI'da tüm süiti başsız olarak çalıştırdığınız bir API platformu olan Apidog ile oluşturacağımız iş akışıdır. Testleri uygulamada bir kez tasarlar, ardından bu tam süiti tek bir komutla herhangi bir pipeline'da çalıştırırsınız. Takip etmek isterseniz, Apidog'u indirin ve kendi API'nizi hazır bulundurun.

button

CI/CD'nin kendisi size yeniyse, kısa versiyonu şudur: sürekli entegrasyon, her commit'te testlerinizi çalıştırır ve sürekli teslimat, bunları geçen derlemeyi yükseltir. CI/CD Nedir ve Nasıl Çalışır makalesinde daha kapsamlı bir dökümümüz var. Bu makalenin geri kalanı, bir pipeline'ınız olduğunu ve API test kısmının orada gerçekten yerini hak etmesini istediğinizi varsayar.

1. API testlerini pipeline'a koyun, açmayı unuttuğunuz bir sekmeye değil

İlk en iyi uygulama, insanların atladığı şeydir: API testlerinizi otomatik olarak, her push işleminde, bir insan karar vermeden çalıştırın. Bir yayından önce manuel olarak çalıştırdığınız bir test süiti, bir güvenlik ağı değil, bir kontrol listesidir. Çalıştırmayı hatırladığınızda, her şeyi bozan değişiklik zaten altı commit geridedir.

Süiti önemli olan aşamaya bağlayın. Çoğu ekip için bu, çekme isteklerinde olur, böylece bozuk bir API main'e ulaşmak yerine birleştirmeyi engeller. İşte GitHub Actions'daki minimal yapı:

name: API Tests
on:
  pull_request:
    branches: [main]
jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run API test suite
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SCENARIO_ID" \
            -e "$APIDOG_ENV_ID" \
            -r cli,junit \
            --out-dir ./test-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
          SCENARIO_ID: ${{ vars.SCENARIO_ID }}
          APIDOG_ENV_ID: ${{ vars.APIDOG_ENV_ID }}

Entegrasyonun tamamı budur. CLI, her doğrulama başarılı olduğunda 0, herhangi biri başarısız olduğunda ise sıfır olmayan bir kodla çıkar, böylece GitHub, ekstra bir bağlantı olmaksızın gerçek bir hatada işi kırmızıya çevirir. Tam GitHub kurulumunu GitHub Actions'ta API Testleri Nasıl Otomatikleştirilir makalesinde ele alıyoruz; bu model herhangi bir çalıştırıcıya uygulanabilir.

İlk en iyi uygulamanın amacı, test etme kararının geliştirici tarafından değil, makine tarafından verilmesidir. İnsanlar unutur. Pipeline'lar unutmaz.

2. Çalıştırma komutunu CI sağlayıcıları arasında taşınabilir tutun

Pipeline'lar göç eder. Ekipler Jenkins'ten GitHub Actions'a geçer, yeni bir depo için GitLab ekler veya uyumluluk için kendi barındırdıkları bir çalıştırıcıyı kullanır. API testleriniz bir sağlayıcının eklenti ekosistemine kaynaklanmışsa, her geçiş yeniden yazma anlamına gelir.

Bunu önlemenin yolu, test çağrısını, herhangi bir çalıştırıcının çağırabileceği tek bir kabuk komutu haline getirmektir. Apidog CLI ile, süitinizi çalıştıran komut, kim çağırırsa çağırsın aynıdır:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit

Aynı satır, bir GitHub Actions run adımında, bir GitLab script bloğunda, bir Jenkins kabuk aşamasında veya bir Travis script bölümünde çalışır. Yalnızca etrafındaki sarmalayıcı değişir. Örneğin GitLab:

api-tests:
  image: node:20
  script:
    - npm install -g apidog-cli
    - apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SCENARIO_ID" -e "$ENV_ID" -r cli,junit
  artifacts:
    when: always
    reports:
      junit: ./test-results/*.xml

Yoğun iş (istek düzenlemesi, doğrulama ifadeleri, ortam çözümü) CLI'da yaşadığı ve test tanımları Apidog'da olduğu için, pipeline YAML'iniz ince kalır. Sağlayıcı değiştirdiğinizde, altı yüz satır yerine altı satır kopyalarsınız. Jenkins varyantı, eğer yığın buysa, Apidog Otomatik Testlerini Jenkins ile CI/CD için Nasıl Entegre Edilir makalesinde detaylandırılmıştır.

3. Sadece durum kodlarına değil, davranışa yönelik doğrulama yapın

Yalnızca 200 OK'yi kontrol eden bir test, API'niz boş bir dizi, yanlış bir para birimi veya istemcinin bir nesne beklediği yerde null döndürürken geçecektir. Yalnızca durum koduna dayalı testler, yeşil pipeline'ların bozuk yanıtlar göndermesinin en büyük tek nedenidir.

Gerçek doğrulama ifadeleri, yanıtın şeklini ve içeriğini kontrol eder: var olan alanlar, tipleri, bir tüketici için önemli olan değerler. Apidog'da bunları yanıtla görsel olarak oluşturursunuz, böylece kafanızdaki bir JSONPath'i tahmin etmek yerine gerçek yükü doğruluyorsunuz. Sağlam bir sipariş arama testi, durumun 200 olduğunu, order.total'in bir sayı olduğunu, currency'nin gönderdiğiniz değere eşit olduğunu ve items dizisinin boş olmadığını doğrular. Bunların her biri bağımsız olarak başarısız olan ayrı bir doğrulama ifadesidir, bu nedenle kırmızı bir derleme size hangi sözleşmenin bozulduğunu söyler.

Üç kural, doğrulama ifadelerinin zaman içinde geçerliliğini korumasını sağlar:

Veriye değil, sözleşmeye yönelik doğrulama yapın. total'in sayı olduğunu kontrol edin, 49.99'a eşit olduğunu değil. Tam değer değişir; tip değişmez.
Doğrulama başına bir endişe. Altı kontrolü tek bir doğrulama ifadesinde birleştirmek, hangisinin başarısız olduğunu gizler.
Olumsuz senaryoları da kapsayın. Kötü girişte bir 400 ve eksik bir token'da bir 401 de sözleşmenizin bir parçasıdır. Bunların hala beklenen gibi davrandığını test edin.

Yeniden düzenlemelere dayanıklı doğrulama ifadeleri yazma konusunda daha derinlemesine bilgi için, API doğrulama ifadeleri rehberimize bakın. Güçlü doğrulama ifadeleri, bir duman testini bir sözleşme testine dönüştüren şeydir ve sözleşme testleri, önemli regresyonları yakalayan şeydir.

4. Ortamları ve sırları yapılandırma olarak yönetin, asla sabit kodlanmış değerler olarak değil

Testleriniz farklı hedeflere karşı çalışır: yerel bir yığın, bir hazırlık API'si, bir üretim duman uç noktası. Temel URL, kimlik doğrulama tokenları ve kiracı kimlikleri bunların arasında değişir. Bunlardan herhangi birini bir teste sabit kodlamak, hazırlık testinin yanlışlıkla üretime ulaşması veya bir token'ın git geçmişinizde kalması demektir.

Ortamları adlandırılmış yapılandırmalar olarak tutun ve farklılıkları enjekte edin. Apidog'da bir ortam, temel URL'yi ve bir hedef için değişkenleri tutar; bir CI çalıştırmasının hangisini kullandığını -e bayrağıyla seçersiniz. Pipeline, erişim token'ını kendi sır deposundan sağlar, asla depodaki bir dosyadan değil:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$STAGING_ENV_ID" \
  -r cli,junit

Aynı senaryo, farklı bir -e değerine işaret edildiğinde, üretim duman testiniz olur. Testte hiçbir şey değişmez; yalnızca çözümlendiği ortam değişir. APIDOG_ACCESS_TOKEN'ı GitHub Secrets'ta, GitLab CI/CD değişkenlerinde veya çalıştırıcınızın kimlik bilgisi yöneticisinde saklayın ve ada göre referans verin. Kural basittir: ortamlar arasında farklılık gösteren veya gizli olan her şey yapılandırmadır ve yapılandırma çalışma zamanında enjekte edilir.

5. Testleri deterministik hale getirin, böylece pipeline güvenilir olur

Değişken bir test, kodunuzla ilgisi olmayan nedenlerle başarısız olan bir testtir. Aynı zamanda bir pipeline'ın güvenilirliğini yok etmenin en hızlı yoludur. Bir süit "bazen başarısız" olduğunda, geliştiriciler yeşile dönene kadar işleri yeniden çalıştırmaya başlar, bu da gerçek bir hatanın artık sahte olanların gürültüsünde saklanması anlamına gelir.

Çoğu API testindeki değişkenlik, birkaç öngörülebilir kaynaktan gelir:

Paylaşılan değişken durum. İki testin aynı e-posta ile bir kullanıcı oluşturması veya bir testin başka bir testin sildiği verilere bağımlı olması. Her test kendi verilerini kurmalı ve kaldırmalı veya izole edilmiş kiracılar kullanmalıdır.
Zamanlama varsayımları. Hazır olmadan önce eşzamansız bir sonucu doğrulamak. Bir işlem sonunda gerçekleşecekse, sabit sayıda saniye beklemek yerine koşulu yoklayın.
Kontrol edemediğiniz gerçek bağımlılıklar. Sizi hız sınırlayan üçüncü taraf bir ödeme sanal alanı veya bakım nedeniyle kapalı olan yukarı akış bir hizmet. Bu sınırları taklit edin, böylece testiniz sizin API'nizi ölçer, başkasının çalışma süresini değil. Apidog, şemasından kararsız bir bağımlılık için bir taklit kurabilir, bu da harici değişkenliği derlemenizden uzak tutar.
Sıra bağımlılığı. Yalnızca belirli bir sırada çalıştırıldığında geçen testler. Bir süit, çalıştırıcılar paralel çalıştığı için herhangi bir sırada çalıştırıldığında geçmelidir.

Determinizm, insanların saygı duyduğu bir pipeline ile etrafından dolaştığı bir pipeline arasındaki farktır. Mühendislik çalışmalarını erken yapın; değişken testler faizi bileşik yapar.

6. API test aşamasını hızlı tutun, yoksa geliştiriciler onu atlayacak

Her çekme isteğinde yirmi dakika süren bir test süiti, geliştiricilerin nefret ettiği ve sonunda devre dışı bıraktığı bir yüke dönüşür. Hız, CI'da isteğe bağlı bir özellik değildir; süitin hiç çalışmasını sağlayan şeydir. Çoğu ekibin hedeflediği, PR'lerde beş dakikanın altında bir API aşamasıdır.

Size yardımcı olacak birkaç kol:

Bağımsız senaryoları paralel çalıştırın. Testleriniz deterministikse (beşinci en iyi uygulama), bunları paralel işlere bölmenizi veya çalıştırıcının dağıtmasını hiçbir şey engellemez. Bağımsız süitler yan yana çalışabilir.
Testlerinizi kademeli yapın. Her PR'de hızlı bir duman süiti ve main'e birleştirmede veya gecelik bir programda tam regresyon süiti çalıştırın. Her testin her commit'i engellemesi gerekmez.
Kurulumu önbelleğe alın. apidog-cli'nin global npm kurulumunu çalıştırmalar arasında önbelleğe almak, her işin kurulum süresini kısaltır.
Yardımcı olduğu yerde hızlıca başarısız olun, yardımcı olmadığı yerde bitirin. Bir PR'de, hızlı geri bildirim vermek için ilk hatada durun. Gecelik tam bir çalıştırmada, bir bozuk uç noktanın kırık diğer kırk tanesini gizlememesi için CLI'nın --on-error continue komutunu kullanın.

İşte GitHub Actions'taki kademeli model, PR'lerde hızlı bir duman çalıştırması ve planlanmış bir zamanda tam süit:

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'   # nightly full regression

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run suite
        run: |
          if [ "${{ github.event_name }}" = "pull_request" ]; then
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$SMOKE_ID" -e "$ENV_ID" -r cli,junit --out-dir ./test-results
          else
            apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t "$FULL_ID" -e "$ENV_ID" -r cli,junit --on-error continue --out-dir ./test-results
          fi
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Çalışan hızlı bir aşama, devre dışı bırakılan kapsamlı bir aşamadan daha değerlidir.

7. Sadece bir konsol metni yığını değil, makine tarafından okunabilir sonuçlar yayınlayın

Bir derleme başarısız olduğunda, "API testleri başarısız oldu" yeterli değildir. Hangi doğrulama ifadesinin, hangi senaryoda, hangi istekte bozulduğunu bilmeniz gerekir. Bin satırlık konsol çıktısı olan kırmızı bir derleme, hiç test olmamasından zar zor daha iyidir; hala birilerinin okuması gerekir.

Çözüm, sonuçları CI sunucunuzun doğal olarak ayrıştırdığı bir formatta yaymaktır. JUnit XML, standart CI test-sonuç formatıdır ve hemen hemen her platform bunu okur. Apidog CLI, junit raporlayıcısı ile bir tane yazar:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -r cli,html,junit \
  --out-dir ./test-results

Bu komut, aynı çalıştırmanın üç görünümünü yayar: canlı konsol çıktısı için cli, bir insanın açabileceği göz atılabilir bir rapor için html ve makine için junit. Pipeline'ınızı XML'e işaretleyin ve platform, bunu yapılandırılmış, test başına sonuçlara dönüştürür:

      - name: Publish test report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-results
          path: ./test-results

if: always() kısmına dikkat edin. Raporun, çalıştırma başarısız olsa bile yayınlanmasını istersiniz, çünkü başarısız bir çalıştırma tam da buna ihtiyaç duyduğunuz zamandır. Getirisi gerçektir: "API derlemesi bozuk" yerine, "ödeme senaryosundaki cart-total doğrulama ifadesi başarısız olmaya başladı" elde edersiniz, bu da hata ayıklama oturumunu bir bakışa dönüştürür.

8. Birleştirmeleri, süit üzerinde dal korumasıyla engelleyin

Hiçbir şeyi engellemeyen geçen bir test süiti sadece bir bildirimdir. CI'ın amacı, bozuk kodu birleştirilemez hale getirmektir ve bu, çoğu ekibin yapılandırdığı bir adım daha gerektirir: dal koruması.

Çıkış kodu yerel işi yapar. Apidog CLI, herhangi bir başarısız doğrulama durumunda sıfır olmayan bir değerle çıktığı için, iş gerçek bir hatada kırmızıya döner. Ancak bir PR'deki kırmızı bir iş, siz kontrolü zorunlu hale getirene kadar sadece tavsiye niteliğindedir. GitHub'da, API testleri kontrolünü main dalında gerekli bir durum kontrolü olarak ayarlayın; birleştirme düğmesi yeşile dönene kadar devre dışı kalır. GitLab ve Bitbucket'ta birleştirme isteği ayarlarında bunun eşdeğeri bulunur.

Bu, regresyonları yakalayan bir süit ile sonradan belgeleyen bir süit arasındaki farktır. Gerekli bir kontrol olmadan, son teslim tarihi baskısı altındaki bir geliştirici birleştirme düğmesine tıklar ve bozuk API, hemen yanında kırmızı bir kontrolle birlikte gönderilir. Engelleme ile platform reddeder. Test bir öneri olmaktan çıkar ve araçların sizin için uyguladığı bir kural haline gelir.

Bunu yedinci en iyi uygulamadan alınan makine tarafından okunabilir sonuçlar ve bir commit durumu entegrasyonuyla eşleştirin, ve Git host'unuz PR'de tam olarak başarısız olan kontrolü satır içinde gösterir. Geri bildirim döngüsü kapanır: push, test, engellendi, düzelt, yeşil, birleştir.

9. API spesifikasyonunuzdan test kapsamı oluşturun, elle yazmak yerine

API testinin en yavaş kısmı, testleri API ile senkronize tutmaktır. Her yeni uç nokta yeni bir test gerektirir; her değişen alan güncellenmiş bir doğrulama ifadesi gerektirir. Elle yapıldığında, testler her zaman API'nin gerisinde kalır ve regresyonların yaşadığı boşluk budur.

Kaldıraç hareketi, testleri sözleşmeden yönlendirmektir. API'nizin bir OpenAPI spesifikasyonu varsa, test iskelelerini buradan oluşturabilirsiniz: uç nokta başına bir istek, şema zaten beklenen yanıt şeklini açıklıyor. Apidog'da, spesifikasyon ve testler aynı çalışma alanında yaşar, böylece bir test senaryosu belgelenmiş uç noktalardan doğrudan oluşturulabilir, onlardan transkripsiyon yapılmaz. Oluşturma akışını OpenAPI Spesifikasyonlarından API Test Koleksiyonları Nasıl Oluşturulur makalesinde ele alıyoruz.

Bu, CI'da önemlidir çünkü spesifikasyon odaklı testler belirli, yaygın bir hatayı yakalar: belgelerinizin vaat ettikleri ile API'nizin döndürdükleri arasındaki farklılık. Test spesifikasyondan oluşturulduğunda ve canlı API'ye karşı çalıştırıldığında, bir uyumsuzluk derlemeyi başarısız eder. Sözleşme yürütülebilir hale gelir. İş anlamını kodlayan doğrulama ifadelerini hala elle yazarsınız, ancak "bu uç nokta var mı ve belgelenmiş şekli döndürüyor mu" gibi sıkıcı kısımları elle yazmazsınız. Bu yükü spesifikasyon taşısın.

10. Senaryoları tekrarlamadan uç durumları kapsamak için veri odaklı testler kullanın

Aynı uç nokta, girişlere göre farklı davranır: geçerli bir sipariş, kredi limitinin üzerinde bir sipariş, bilinmeyen SKU'lu bir sipariş, desteklenmeyen para biriminde bir sipariş. Her biri için ayrı bir senaryo yazmak, süitlerin yüzlerce neredeyse aynı, kimsenin bakmadığı teste dönüşmesine neden olur.

Veri odaklı testler, tek bir senaryoyu birçok girdi satırına karşı çalıştırır. İsteği ve doğrulama ifadelerini bir kez tanımlar, ardından bir vaka tablosu beslersiniz. Apidog CLI, -d bayrağıyla bir veri dosyası alır:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t "$SCENARIO_ID" \
  -e "$ENV_ID" \
  -d ./test-data/orders.csv \
  -r cli,junit \
  --out-dir ./test-results

orders.csv dosyasındaki her satır, kendi geçiş veya başarısızlığıyla birlikte bir yineleme olur. Tek senaryo, tek CLI çağrısı, tam uç durum kapsamı ve hangi girdi satırlarının başarısız olduğunu gösteren bir JUnit raporu. Bu, süitinizi küçük ve kapsamınızı geniş tutar, bu da CI'da tam olarak istediğiniz dengeyi sağlar. CSV veya JSON ile veri odaklı API testi rehberimiz, veri dosyasının yapılandırılması konusunda daha derinlemesine bilgi verir.

Bu model, özellikle doğrulama mantığı ve fiyatlandırma kuralları gibi, tek bir uç noktanın en çok dal ve sessizce gerileme yollarına sahip olduğu yerlerde en çok işe yarar.

11. Gerçek ortama karşı dağıtım sonrası duman testi çalıştırın

Hazırlık ortamına karşı geçen testler, derlemenin iyi olduğunu söyler. Dağıtımın çalıştığını söylemezler. Yapılandırma kayması, eksik bir ortam değişkeni, yanlış yönlendirilmiş bir yük dengeleyici, süresi dolmuş bir sertifika: bunların hepsi birleştirme öncesi her testi geçer ve yalnızca gerçekten dağıttığınız ortamda bozulur.

Koruyucu, dağıtımdan sonra, canlı hedefe karşı çalışan bir duman testidir. Bu küçük, hızlı bir süittir, sadece kritik yollar, kimlik doğrulama akışınız, en önemli okuma ve yazma uç noktalarınız, üretime veya yeni dağıtılan ortama işaret eder. Çalıştırma komutu taşınabilir olduğu (ikinci en iyi uygulama) ve ortamlar sadece yapılandırma olduğu (dördüncü en iyi uygulama) için, bu, farklı bir -e ile aynı süittir:

  smoke-after-deploy:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t "$SMOKE_SCENARIO_ID" \
            -e "$PROD_ENV_ID" \
            -r cli,junit \
            --out-dir ./smoke-results
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

Duman testi başarısız olursa, bu, kullanıcılar fark etmeden geri almanız için bir sinyaldir. Mavi-yeşil veya kanarya dağıtımları yapan ekipler için, trafiği ona geçirmeden önce yeni renge karşı duman süitini çalıştırırsınız, böylece ilk gerçek kullanıcınız asla bozuk dağıtımı bulan kişi olmaz. Maliyet, bir dakikalık pipeline süresidir. Alternatif, bir destek talebinden öğrenmektir.

12. Test süitini bitirdiğiniz bir kurulum olarak değil, sürdürdüğünüz bir kod olarak ele alın

Son en iyi uygulama bir zihniyettir. Bir CI test süiti tamamladığınız bir proje değildir; koruduğu API'nin yanında sürdürdüğünüz bir varlıktır. Pipeline'ları güvenilir kalan ekipler, değişken bir testi bir hata, yavaş bir aşamayı teknik borç ve kapsamdaki bir boşluğu gerçekleşmeyi bekleyen bir regresyon olarak ele alanlardır.

Bir süiti uzun vadede sağlıklı tutan birkaç alışkanlık:

Özellikle birlikte testi ekleyin. Yeni bir uç nokta, aynı PR'de kendi senaryosuyla birlikte gelir, asla gelmeyen bir takip ile değil.
Değişkenlikleri göründükleri gün düzeltin. Karantinaya alınmış değişken bir test, üzerinde yeşil ışık yanan bir kapsam boşluğudur. continue-on-error'ın kalıcı olmasına izin vermeyin.
Süitin neleri kapsamadığını gözden geçirin. Periyodik olarak hangi uç noktaların doğrulama ifadesi olmadığını kontrol edin. Test edilmemiş olanlar, bir sonraki kesintinin başladığı yerlerdir.
Pipeline yapılandırmasını sürüm kontrolünde tutun. YAML'niz, ortam tanımlarınız ve test verileriniz depoda yaşar, diğer değişiklikler gibi gözden geçirilir.

Test tanımları Apidog'da olduğu ve pipeline sadece ince bir çağrı içerdiği için, bu bakımın çoğu kolayca gerçekleşir: uygulamada senaryolar ve doğrulama ifadeleri eklersiniz ve CI yapılandırması zar zor değişir. Bunu doğru yapan ekipler, zamanlarını YAML ile uğraşmak yerine kapsamı geliştirmeye harcarlar. Büyük süitleri düzenlemeye daha geniş bir bakış için, Apidog Test Süitleri: API Test Otomasyonuna Daha Akıllı Bir Yaklaşım makalesine bakın.

Hepsini bir araya getirme

Bu on iki uygulama birbirini güçlendirir. Taşınabilir çalıştırma komutları, dağıtım sonrası duman testlerini önemsiz hale getirir. Deterministik testler paralelliği güvenli hale getirir, bu da aşamayı hızlı tutar, bu da geliştiricilerin onu kullanmasını sağlar. Makine tarafından okunabilir sonuçlar, dal korumasını anlamlı hale getirir, çünkü geçit bir metin yığını yerine belirli bir başarısız kontrolü işaret eder. Spesifikasyon odaklı ve veri odaklı testler, süitin kapsamlı olmasını sağlarken bakımı yavaşlatmaz.

Ortak temel, testlerinizi sözleşmenize yakın tutmak ve tek bir komutla çalıştırılabilir olmaktır. Apidog iş akışı tek bir cümlede şöyledir: API'yi ve testlerini tek bir yerde tasarlayın, ardından bu tam süiti herhangi bir pipeline'da apidog run ile çalıştırın. CLI, hata durumunda sıfır olmayan bir değerle çıkar, CI'ınızın ayrıştırması için JUnit yayar ve GitHub Actions, GitLab, Jenkins veya kendi barındırdığınız bir çalıştırıcı çağırsa da aynı şekilde davranır.

Küçükten başlayın. Gerçek doğrulama ifadeleri ve gerekli bir durum kontrolü ile kritik bir senaryoyu PR pipeline'ınıza bağlayın. Bu döngüyü güvenilir hale getirin, sonra diğerlerini katmanlandırın: kademeli çalıştırmalar, veri odaklı uç durumlar, dağıtım sonrası duman testi. Güvendiğiniz bir pipeline, yalnızca bir şey gerçekten bozuk olduğunda kırmızıya dönen ve yalnızca gerçekten güvenli olduğunda yeşile dönendir. Apidog'u indirin ve ilk senaryoyu bugün oluşturun.

button

SSS

CI ve CI/CD'de API testi arasındaki fark nedir? CI (sürekli entegrasyon), regresyonları erken yakalamak için her commit'te veya çekme isteğinde API testlerinizi otomatik olarak çalıştırır. CD (sürekli teslimat), bu kontrolleri geçtikten sonra bir derlemeyi bir dağıtım hedefine yükseltir. API testleri her ikisinde de yer alır: birleştirme öncesi bir süit entegrasyonu engeller ve dağıtım sonrası bir duman süiti teslimatı doğrular. Aynı Apidog CLI komutu her iki aşamaya da hizmet eder.

Bir pipeline'da API testlerini çalıştırmak için kod yazmam gerekiyor mu? Hayır. İstekleri ve doğrulama ifadelerini Apidog'da görsel olarak oluşturursunuz, ardından tek bir apidog run komutuyla başsız olarak çalıştırırsınız. Pipeline'ın yalnızca bu tek komuta ihtiyacı vardır, bu da CI yapılandırmanızı ince tutar ve Kalite Güvence mühendislerinin kod tabanlı bir çerçeve sürdürmek zorunda kalmadan testleri sahiplenebileceği anlamına gelir. Tam adım adım açıklama CI/CD'de API Testleri Nasıl Otomatikleştirilir makalesindedir.

CI'da API testlerimin değişken olmasını nasıl durdurabilirim? En büyük üç neden paylaşılan değişken test verileri, eşzamansız işlemler üzerindeki zamanlama varsayımları ve kontrolsüz üçüncü taraf bağımlılıklarıdır. Her teste kendi verilerini verin, sabit bir süre beklemek yerine eşzamansız koşullar için yoklama yapın ve kontrol edemediğiniz harici sınırları taklit edin. Herhangi bir sırada ve herhangi bir çalıştırmada geçen bir süit hedefinizdir.

Başarısız bir API testinin birleştirmeyi engellemesini nasıl sağlarım? İki kısım. İlk olarak, test çalıştırıcısının hata durumunda sıfır olmayan bir değerle çıkması gerekir; Apidog CLI, herhangi bir başarısız doğrulama durumunda bunu yapar, böylece iş otomatik olarak kırmızıya döner. İkinci olarak, o işi Git host'unuzun dal koruma kurallarında gerekli bir durum kontrolü olarak işaretleyin. Birleştirme düğmesi, kontrol geçene kadar devre dışı kalır.

Aynı API testlerini GitHub Actions, GitLab ve Jenkins'te çalıştırabilir miyim? Evet. Test mantığı Apidog'da olduğu ve pipeline yalnızca apidog run komutunu çağırdığı için, komut sağlayıcılar arasında aynıdır; yalnızca çevreleyen YAML veya pipeline betiği değişir. Bu taşınabilirlik, CI sağlayıcılarını taşımayı yeniden yazmak yerine altı satırlık bir düzenlemeye dönüştüren şeydir. GitHub'a özel kurulum için GitHub Actions'ta API Testleri Nasıl Otomatikleştirilir makalesine bakın.

API test aşamam ne kadar hızlı olmalı? Çekme isteklerinde beş dakikanın altını hedefleyin. Buraya, PR'lerde hızlı bir duman süiti ve gecelik tam regresyon süiti çalıştırarak, bağımsız senaryoları paralelleştirerek ve CLI kurulumunu önbelleğe alarak ulaşın. Yavaş bir aşama, geliştiricilerin sonunda devre dışı bırakacağı bir aşamadır, bu da amacını yitirir.