TeamCity'de Otomatik API Testleri Nasıl Çalıştırılır?

API'niz dizüstü bilgisayarınızdaki her testi geçiyor. Sonra bir ekip arkadaşı, bir alanı yeniden adlandıran bir dalı birleştiriyor ve mobil bir istemci üretimde çökmeye başlayana kadar kimse fark etmiyor. Manuel test bunu kaçırdı çünkü kimse paketi yeniden çalıştırmadı. Sürekli entegrasyonun kapatmak için oluşturulduğu boşluk tam olarak budur ve TeamCity bunu kapatmak için en güçlü araçlardan biridir.

JetBrains'in CI/CD sunucusu TeamCity, kod her indiğinde derleme hattınızı çalıştırır. Kimse bir düğmeye basmadan derleyebilir, test edebilir, paketleyebilir ve dağıtabilir. Ekiplerin genellikle atladığı kısım, gerçek API testlerini bu hatta bağlamaktır. Birimleri test ederler, derlemenin derlendiğini test ederler ve API'yi körü körüne yayınlarlar. Yeniden adlandırılmış bir alan, bir uç durumda 500 hatası, bozuk bir kimlik doğrulama akışı; bunların hiçbiri bir insan uç noktaya ulaşana kadar ortaya çıkmaz.

Bu kılavuz, TeamCity içinde otomatik API testlerini baştan sona çalıştırmayı anlatmaktadır. Testlerinizi Apidog'da tasarlayacak ve doğrulayacak, ardından TeamCity derleme adımı olarak Apidog CLI aracılığıyla başsız bir şekilde çalıştıracaksınız. Sonuç, API'niz hatalı davranmaya başladığı anda, kötü bir yanıt kullanıcıya ulaşmadan önce derlemeyi başarısız kılan bir hattır.

Ne inşa edeceksiniz

Sonunda şunlara sahip olacaksınız:

• Git deponuza bağlı bir TeamCity projesi
• Her push'ta tetiklenen bir VCS tetikleyicisine sahip bir derleme yapılandırması
• API test paketinizi Apidog CLI aracılığıyla çalıştıran bir derleme adımı
• TeamCity Testler sekmesinde görünen ayrıştırılmış test sonuçları
• Bir uç nokta bozulduğunda kırmızıya dönen ve birleştirmeyi engelleyen bir derleme

Aynı desen, küçük bir dahili hizmet veya yüzlerce uç noktaya sahip genel bir API için de geçerlidir. Bunu, boru hattı kodunu düzenleyerek değil, Apidog'a test senaryoları ekleyerek ölçeklendirirsiniz.

API testleri neden sadece makinenizde değil, TeamCity'de yer almalı?

Yerel testin ölümcül bir kusuru vardır: birinin çalıştırmayı hatırlamasına bağlıdır. CI, insanı döngüden çıkarır. Her commit, aynı ortamda, aynı iddialarla aynı paketi tetikler. "Benim makinemde çalışıyor" diye bir şey yoktur; çünkü makine yoktur; tanımladığınız adımları tam olarak çalıştıran bir derleme aracısı vardır.

TeamCity, bazı somut nedenlerle buna uygun bir çözümdür:

• Derleme zincirleri. API test adımını bir hazırlık ortamına dağıtım adımına bağlı hale getirebilirsiniz, böylece testler her zaman yeni dağıtılan bir derlemeye karşı çalışır, asla eski bir derlemeye karşı değil.
• Test geçmişi. TeamCity, yüzlerce derlemede hangi testlerin geçtiğini ve başarısız olduğunu takip eder. Bir test sorun çıkarmaya başladığında, tam olarak hangi commit'in bunu başlattığını görürsünüz.
• İnceleme ve sessize alma. Sorunlu bir uç nokta, herkesin birleştirmelerini engellemek yerine sessize alınabilir ve bir sahibine atanabilir.
• Aracı havuzları. Ağır paketler özel aracılarda çalıştırılır, böylece derleme derlemelerinizi yavaşlatmazlar.

Ancak, TeamCity API'nizi nasıl çağıracağını veya yanıtı nasıl kontrol edeceğini bilmez. Verdiğiniz herhangi bir komutu çalıştırır. Dolayısıyla asıl iş, tüm API paketinizi çalıştıran ve bir şeyler başarısız olduğunda sıfırdan farklı bir kodla çıkan tek bir komut üretmektir. İşte burada test tasarımı devreye girer.

Adım 1: Apidog'da API testlerinizi tasarlayın ve doğrulayın

TeamCity'ye dokunmadan önce, katılımsız olarak çalışan testlere ihtiyacınız var. Bir JSON yanıtını incelemenizi gerektiren bir test, CI'da işe yaramaz. Her kontrol, makinenin değerlendirebileceği bir iddia olmalıdır: durum kodu 200, `id` alanı bir sayı, yanıt 800 ms'den kısa sürede geri geldi.

Apidog tam da bunun için yapıldı. İsteği tasarlar, ardından yanıtı otomatik olarak doğrulayan API iddialarını eklersiniz; durum kodları, JSON Şema uyumluluğu, belirli alan değerleri, yanıt süresi. İstekleri bir senaryo halinde zincirleyebilir, böylece bir oturum açma çağrısının çıktısı belirteci bir sonraki isteğe besleyebilir. Yaygın durumlar için komut dosyası oluşturmaya gerek yoktur ve ihtiyacınız olduğunda tam komut dosyası oluşturma mevcuttur.

Bir e-ticaret API'si için gerçekçi bir senaryo şöyle görünebilir:

1. Test kimlik bilgileriyle `POST /auth/login`, `200` olduğunu iddia et, taşıyıcı belirteci bir değişkene çıkar.
2. Bu belirteçle `GET /products?category=books`, `200` olduğunu iddia et, yanıtın bir dizi olduğunu iddia et, her öğenin `price` değerinin 0'dan büyük olduğunu iddia et.
3. Bir ürün kimliğiyle `POST /cart/items`, `201` olduğunu iddia et, döndürülen sepet toplamının öğe fiyatıyla eşleştiğini iddia et.
4. `GET /cart`, öğe sayısının 1 olduğunu iddia et.

Her adımın kendi başına geçen veya başarısız olan iddiaları vardır. Önce senaryoyu Apidog içinde çalıştırın ve hazırlık ortamınıza karşı başarılı olduğunu doğrulayın. Elle çalıştırdığınızda geçemezse, CI'da asla geçemez. İlgili senaryoları bir test paketi halinde gruplandırın, böylece her senaryoyu tek tek çalıştırmak yerine hepsini tek bir komutla çalıştırabilirsiniz.

Testleri bu şekilde oluşturmanın avantajı, manuel hata ayıklama için kullandığınız aynı senaryoların CI paketiniz haline gelmesidir. İki paralel test kümesi sürdürmezsiniz; biri keşif için bir GUI'de, diğeri otomasyon için kodda. Tek bir doğruluk kaynağıdır. REST Assured gibi kod öncelikli bir framework'ten geliyorsanız, en çok zaman kazandıran kısım burasıdır: her uç nokta için tekrar tekrar ortak istek/iddia kodu yazmayı bırakırsınız.

Birlikte oluşturmak isterseniz Apidog'u indirin. Başlamak ücretsizdir ve CLI aynı araç zincirinin bir parçasıdır.

Adım 2: Önce Apidog CLI'yi yerel olarak çalıştırın

Yeni bir komutu asla ilk kez CI içinde hata ayıklamayın. Bir CI sunucusundaki geri bildirim döngüsü acımasızdır; push yaparsınız, bir aracı beklersiniz, bir log okursunuz, tek bir karakteri düzeltirsiniz, tekrar push yaparsınız. Komutun makinenizde çalıştığını kanıtlayın, ardından çalışan sürümü TeamCity'ye kopyalayın.

Apidog CLI Node.js üzerinde çalışır, bu yüzden npm ile global olarak yükleyin:

npm install -g apidog-cli

Orada olduğunu doğrulayın:

apidog --version

Şimdi test senaryonuzu çalıştırın. CLI, bir senaryoyu veya paketi doğrudan Apidog projenizden kimlik referansıyla, bir erişim belirteciyle kimlik doğrulaması yaparak veya yerel olarak dışa aktarılmış bir dosyadan çalıştırabilir. Çevrimiçi yaklaşım, testlerinizi tek doğruluk kaynağı olarak tutar; ekibinizin Apidog'da düzenlediği her şey, unutulacak bir dışa aktarma adımı olmadan CI'da çalışır.

Apidog hesap ayarlarınızdan bir erişim belirteci oluşturun, ardından şunu çalıştırın:

apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -e "$APIDOG_ENV_ID" \
 -r cli,html,junit

Burada dikkat edilmesi gereken birkaç şey var:

• `--access-token` çalıştırmanın kimliğini doğrular. Bunu doğrudan burada geçirin veya `apidog login --with-token` ile bir kez oturum açın.
• `-e`, hangi ortama karşı çalıştırılacağını seçer; hazırlık, üretim-sadece-okuma, Apidog'da tanımladığınız herhangi bir şey. Bu kimliği değiştirerek aynı testleri farklı temel URL'lere yönlendirirsiniz.
• `-r`, raporlayıcıları seçer. `cli` insan tarafından okunabilir çıktıyı konsola yazdırır, `html` göz atabileceğiniz bir rapor üretir ve JUnit formatındaki bir rapor, TeamCity'nin bireysel test sonuçlarını ayrıştırmasına ve görüntülemesine olanak tanır.

Çalıştırma tamamlandığında, her şey geçerse CLI 0 ile, herhangi bir iddia başarısız olursa sıfırdan farklı bir kodla çıkar. Bu çıkış kodu CI'daki tüm oyundur: sıfırdan farklı bir çıkış, TeamCity'ye derlemeyi başarısız olarak işaretlemesini söyleyen şeydir.

Birçok girişe karşı çalışması gereken testler için CLI, veri odaklı çalıştırmaları destekler. Bir CSV veya JSON dosyasına işaret edin ve her satır için senaryoyu bir kez yineler:

apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -d test-data/checkout-cases.csv \
 -r cli,junit

Yüz senaryo yazmadan yüzlerce ürün kimliğini veya geçersiz yük tablolarını bu şekilde test edersiniz. Her satır, kendi geçme/kalma sonucuyla kendi iterasyonu haline gelir.

Yerel olarak yeşil çıktıyı gördüğünüzde, güvendiğiniz bir komuta sahipsiniz demektir. Kopyalayın. Tam olarak o komut TeamCity'ye girer.

Adım 3: TeamCity'yi deponuza bağlayın

Şimdi TeamCity'ye geçin. Bu adımın amacı, TeamCity'ye bir proje vermek, onu kodunuza yönlendirmek ve her push'ta derlemeleri tetiklemesini sağlamaktır.

TeamCity'yi ilk kez çalıştırıyorsanız, en basit yol resmi Docker imajıdır. Birkaç dakika içinde çalışan bir sunucuya sahip olmanızı sağlar:

docker run -d --name teamcity-server \
 -v ~/teamcity/datadir:/data/teamcity_server/datadir \
 -v ~/teamcity/logs:/opt/teamcity/logs \
 -p 8111:8111 \
 jetbrains/teamcity-server

`http://localhost:8111` adresini açın, ilk çalıştırma kurulumunu (veritabanı seçimi, yönetici hesabı) tamamlayın ve kontrol paneline ulaşırsınız. Üretim kurulumları uygun bir harici veritabanı ve özel derleme aracıları kullanır, ancak bu kılavuzu takip etmek için paketlenmiş aracı yeterlidir.

Projeyi oluşturun:

1. Yönetim'e gidin ve Proje Oluştur'u seçin.
2. Depo URL'sinden seçin ve Git uzaktan depoyu (HTTPS veya SSH) yapıştırın.
3. Depo özel ise kimlik bilgilerini ekleyin; bir dağıtım anahtarı veya kişisel erişim belirteci.
4. TeamCity depoyu tarar ve derleme adımlarını otomatik olarak algılaması gerekir. Buna izin verebilirsiniz, ancak API testleri için bir sonraki bölümde adımı kendiniz yapılandırmak daha temizdir.

TeamCity bir VCS kökü (deponuzla bağlantısı) ve bir derleme yapılandırması (çalışan adımlar kümesi) oluşturur. VCS kökü yerindeyken, derlemelerin otomatik olarak başlaması için tetikleyiciyi ayarlayın:

1. Derleme yapılandırmanızı açın ve Tetikleyiciler'e gidin.
2. Bir VCS Tetikleyicisi ekleyin.
3. Varsayılan kuralı bırakın, böylece izlenen dala yapılan her değişiklik bir derlemeyi sıraya sokar.

Buradan itibaren, deponuza yapılan her push bir derlemeyi tetikleyecektir. Şu anda bu derleme faydalı hiçbir şey yapmıyor; bir sonraki adım ona API test komutunu verecektir.

Adım 4: Apidog CLI'yi bir derleme adımı olarak ekleyin

Bu, kurulumun çekirdeğidir. Aracınıza CLI'yi yükleyen ve paketinizi çalıştıran bir derleme adımı ekliyorsunuz.

Derleme yapılandırmanızda, Derleme Adımları'nı açın ve Komut Satırı türünde yeni bir adım ekleyin. Özel komut dosyası'nı seçin ve yapıştırın:

#!/bin/bash
set -e

# Apidog CLI'yi derleme aracısına yükle
npm install -g apidog-cli

# API test paketini çalıştır ve TeamCity için bir JUnit raporu oluştur
apidog run \
 --access-token "%env.APIDOG_ACCESS_TOKEN%" \
 -e "%env.APIDOG_ENV_ID%" \
 -r cli,junit \
 --out-dir reports

Bu, yerel olarak kanıtladığınız aynı komut, CI için iki değişiklikle. İlk olarak, `set -e` komut dosyasının herhangi bir hatada durmasını sağlar. İkincisi, sırlar sabit kodlanmak yerine TeamCity parametreleri (%env.APIDOG_ACCESS_TOKEN%) olarak referans alınır; bunları bir sonraki adımda tanımlayacaksınız.

Derleme aracınızda Node.js zaten yoksa, zincirin başında yükleyin veya Node içeren bir aracı imajı kullanın. Resmi TeamCity aracı Docker imajları ve çoğu bulut aracı havuzu Node ile birlikte gelir. Adımı `node:20` gibi bir Docker imajında çalıştıracak şekilde ayarlayarak tüm adımı bir Node kapsayıcısı içinde de çalıştırabilirsiniz.

Doğru yapılması gereken bir detay: CLI, API'niz dağıtıldıktan ve erişilebilir olduktan *sonra* çalışmalıdır. TeamCity, yeni dağıttığı bir hizmeti hazırlık ortamında test ediyorsa, testi derlemesini bir Anlık Görüntü Bağımlılığı veya Bir Derleme Zinciri kullanarak dağıtım derlemesine bağlı hale getirin. Bu, testlerin her zaman bu commit'in ürettiği API sürümüne isabet etmesini garanti eder, asla önceki sürümüne değil.

Adım 5: Gizli bilgileri TeamCity parametreleri olarak saklayın

Erişim belirteciniz bir kimlik bilgisidir. Derleme komut dosyasında, deponuzda veya derleme günlüğünde bulunmaması gerekir. TeamCity'nin bunun için birinci sınıf bir yeri vardır.

1. Derleme yapılandırmanızda (veya yapılandırmalar arasında paylaşmak için üst projede) Parametreler'i açın.
2. `env.APIDOG_ACCESS_TOKEN` adında yeni bir parametre ekleyin.
3. Spesifikasyonunu Parola olarak ayarlayın. Bu, değeri kullanıcı arayüzünde maskeler ve derleme günlüklerinden temizler.
4. Apidog erişim belirtecinizi değer olarak yapıştırın.
5. `env.APIDOG_ENV_ID`'yi ortam kimliğinizle aynı şekilde ekleyin (bu gizli değildir, ancak onu bir parametre olarak tutmak, komut dosyasını düzenlemeden ortamları değiştirmenize olanak tanır).

Bunları derleme yapılandırma düzeyinde değil, proje düzeyinde tanımlamak, o proje altındaki her API test derlemesinin bunları devralması anlamına gelir. Belirteci bir kez döndürün ve her hat yeni değeri alır.

Bir parola parametresi, TeamCity'de güvenli bir şekilde yaşayan bir belirteç ile tüm ekibin okuyabileceği bir günlük dosyasına sızan bir belirteç arasındaki farktır. Ona bir veritabanı parolasına davrandığınız gibi davranın.

Adım 6: TeamCity Testler sekmesinde test sonuçlarını gösterin

Sadece kırmızıya dönen bir derleme, bir şeylerin bozulduğunu söyler. Hangi testin bozulduğunu gösteren bir derleme, nereye bakmanız gerektiğini söyler. JUnit raporu size bunu verir.

`-r junit` raporlayıcısı, TeamCity'nin doğal olarak okuduğu standart CI test sonucu formatı olan JUnit formatında bir XML dosyası yazar. TeamCity'yi bir XML Rapor İşleme derleme özelliğiyle bu dosyaya yönlendirirsiniz.

1. Derleme yapılandırmanızda Derleme Var'ı açın.
2. XML rapor işlemeyi ekleyin.
3. Rapor türünü Ant JUnit olarak ayarlayın.
4. İzleme yolunu çıktınızla eşleşecek şekilde ayarlayın, örneğin `reports/*.xml`.

Bir derleme çalıştırın. Açın ve Testler sekmesine tıklayın. Her senaryoyu ve iddiayı, geçme/kalma durumu ve zamanlaması ile bireysel bir test olarak göreceksiniz. Bir test başarısız olduğunda, TeamCity hata mesajını satır içinde gösterir, bunu başlatan commit'e bağlar ve gelecekteki derlemelerde izler. Aynı test art arda iki kez başarısız olursa, TeamCity bunu geçici bir sorun yerine yeni bir hata olarak işaretleyebilir.

Bu, JUnit çıktısını daha önce seçmenin karşılığıdır. Olmasaydı, bir hata bir kırmızı derleme ve bir konsol metni duvarı olurdu. Bununla birlikte, "API derlemesi bozuk" ifadesini "sepet-toplamı iddiası `a3f9c2` commit'inde başarısız olmaya başladı" ifadesine dönüştüren yapılandırılmış, aranabilir bir test geçmişi elde edersiniz.

Adım 7: Derlemeyi başarısız kılın ve birleştirmeyi engelleyin

Tüm bunların amacı, kötü kodun birleştirilmesini engellemektir. Bunu sağlayan iki şey var.

İlk olarak, çıkış kodu. Apidog CLI herhangi bir başarısız iddiada sıfırdan farklı bir kodla çıktığı ve komut dosyanız `set -e` kullandığı için, başarısız bir test derleme adımını başarısız kılar, bu da derlemeyi başarısız kılar. Ekstra bir şey yapılandırmanıza gerek yoktur; başarısız bir API testi varsayılan olarak başarısız bir derlemedir.

İkinci olarak, birleştirme geçidi. Ekibiniz çekme veya birleştirme istekleriyle çalışıyorsa, Git ana bilgisayarınızı (GitHub, GitLab, Bitbucket), birleştirmeden önce TeamCity kontrolünün geçmesini gerektirecek şekilde yapılandırın. TeamCity, derleme durumunu bir Commit Status Publisher derleme özelliği aracılığıyla commit'e geri bildirir:

1. Commit Status Publisher derleme özelliğini ekleyin.
2. VCS barındırma sağlayıcınızı seçin.
3. TeamCity'nin durumları göndermesi için bir erişim belirteci ekleyin.

Şimdi bir katkıda bulunan bir PR açar, TeamCity API paketini dalına karşı çalıştırır ve birleştirme düğmesi, paket yeşil olana kadar devre dışı kalır. Bu kılavuzun başındaki yeniden adlandırılmış alan senaryosu, ana dala ulaşmadan önce bu dalda burada yakalanır.

Gerçekçi bir tam boru hattı

Parçaları bir araya getirdiğimizde, bir API test boru hattı için çalışan bir derleme yapılandırması şöyle görünür:

• Git deponuza işaret eden bir VCS kökü, ana dalda ve PR dallarında bir VCS tetikleyicisi ile.
• Derleme Adımı 1: hizmeti bir hazırlık ortamına dağıtın (veya aracıda bir Docker kapsayıcısında çalıştırın).
• Derleme Adımı 2: Adım 4'teki Apidog CLI komutu, paketinizi bu hazırlık ortamına karşı çalıştırıyor.
• Derleme Var: `reports/*.xml` okuyan XML rapor işleme.
• Derleme Var: Git ana bilgisayarınıza geri raporlama yapan Commit Status Publisher.
• Parametreler: `env.APIDOG_ACCESS_TOKEN` (şifre) ve `env.APIDOG_ENV_ID`.

Tüm CI yapılandırmasını sürüm kontrolünde tutan ekipler için TeamCity, tüm bunları UI'da tıklamak yerine depoya kaydedilmiş bir Kotlin DSL (`.teamcity/settings.kts`) içinde tanımlamayı destekler. Derleme adımı her iki durumda da aynı `apidog run` komutudur; DSL sadece yapılandırmayı kod olarak tanımlar, böylece her şeyle birlikte incelenir ve sürümlendirilir.

Paketi sadece her push'ta değil, daha fazlasında çalıştırabilirsiniz. Hazırlık ortamına karşı her gece tam regresyon paketini çalıştırmak için bir Zamanlama Tetikleyicisi ekleyin, böylece commit'ler arasında meydana gelen sapmaları yakalarsınız; değişen bir üçüncü taraf bağımlılığı, garip bir duruma giren bir veritabanı. Gece API çalıştırmaları ucuz bir sigortadır ve sabahın ilk commit'inin dünün bozuk ortamını miras almasını engeller.

Diğer CI platformlarıyla karşılaştırması

Buradaki desen taşınabilir. Testlerinizi çalıştıran komut (erişim belirteci ve JUnit raporlayıcısıyla `apidog run`), hangi CI sunucusu çağırırsa çağırsın aynıdır. Yalnızca sarmalayıcı değişir:

• GitHub Actions'da aynı komutu bir iş akışı YAML adımına koyarsınız. Bunu GitHub Actions'da API Testleri Nasıl Otomatikleştirilir makalesinde ele alıyoruz.
• Jenkins'te bir `Jenkinsfile` aşamasına gider. Apidog Otomatik Testleri CI/CD için Jenkins ile Nasıl Entegre Edilir makalesine bakın.
• Herhangi bir platformda daha geniş strateji CI/CD'de API Testleri Nasıl Otomatikleştirilir makalesindedir.

Hala bir CI sunucusu seçiyorsanız, en iyi CI/CD araçları karşılaştırmamız TeamCity'nin alternatifler arasında nasıl bir yere sahip olduğunu açıklıyor. TeamCity'nin güçlü yönleri derleme zincirleri, ayrıntılı test geçmişi ve Kotlin DSL'sidir; JetBrains ekosisteminde zaten bulunan veya karmaşık çok aşamalı boru hatları çalıştıran ekipler için güçlü bir seçimdir.

Yaygın sorunlar ve bunları nasıl çözebileceğiniz

Derleme `apidog` komutunu bulamıyor. Node.js aracıya kurulu değil veya global npm bin dizini aracının PATH'inde değil. Zincirin başında bir Node yükleme adımı ekleyin veya adımı bir `node:20` Docker imajı içinde çalıştırın.

Testler yerel olarak geçiyor ancak CI'da bağlantı hatalarıyla başarısız oluyor. Derleme aracı API'nize ulaşamıyor. Dizüstü bilgisayarınızın VPN'inde çözümlenen bir hazırlık URL'si, bir bulut aracısından ulaşılamayabilir. `-e` ile seçtiğiniz ortamın, aracının gerçekten ulaşabileceği bir ana bilgisayarı işaret ettiğini ve gerekli ağ erişimi veya güvenlik duvarı kurallarının aracıyı kapsadığını doğrulayın.

Kimlik doğrulama sadece CI'da başarısız oluyor. Parola parametresinin komut dosyasında referans verildiği gibi doğru yazıldığından ve belirtecin süresinin dolmadığından emin olun. Yaygın bir hata, `APIDOG_ACCESS_TOKEN` tanımlarken komut dosyasının `%env.APIDOG_ACCESS_TOKEN%` okumasıdır; `env.` ön eki önemlidir.

Testler dalgalı; aynı kodda geçiyor ve başarısız oluyorlar. Genellikle bir zamanlama veya veri sıralama sorunudur. Yavaş uç noktaları ortaya çıkarmak için Apidog'un yanıt süresi iddialarını kullanın ve çalıştırmaların birbirlerinin artıklarına bağlı olmaması için her senaryonun kendi verilerini kurmasını ve kaldırmasını sağlayın. TeamCity'nin sessize alma ve inceleme özelliği, temel nedeni düzeltirken dalgalı bir testi karantinaya almanıza olanak tanır, böylece herkesi engellemeyi durdurur.

Derleme çalışmasına rağmen Testler sekmesi boş. XML rapor işleme yolu, CLI'nin raporu yazdığı yerle eşleşmiyor. Komuttaki `--out-dir` ve derleme özelliğindeki izleme yolunun aynı yeri işaret ettiğini doğrulayın.

Sıkça Sorulan Sorular

TeamCity'de API testleri çalıştırmak için kod yazmam gerekiyor mu? Hayır. Testleri Apidog'da iddialarla görsel olarak tasarlarsınız ve TeamCity'deki tek "kod", bir Komut Satırı derleme adımındaki tek satırlık `apidog run` komutudur. Bu, REST Assured gibi kod öncelikli bir yaklaşımdan temel farktır; burada her uç nokta için elle yazılmış istek ve iddia kodu gerekir.

Testleri farklı ortamlara karşı çalıştırabilir miyim? Evet. Her ortamı (hazırlık, üretim öncesi, üretim-sadece-okuma) Apidog'da tanımlayın, ardından `-e` ortam kimliği parametresini değiştirerek CI'da hangisinin çalışacağını değiştirin. Aynı testler, farklı bir temel URL'yi işaret ederek herhangi bir ortama karşı çalışır.

TeamCity'de erişim belirtecimi nasıl güvende tutarım? Onu TeamCity parametresi olarak Parola belirtimiyle saklayın. Bu, onu UI'da maskeler ve derleme günlüklerinden temizler. Asla derleme komut dosyasına sabit kodlamayın veya deponuza commit etmeyin. Tüm boru hatları için bir kez döndürebilmek için proje düzeyinde tanımlayın.

Başarısız bir API testi birleştirmeyi gerçekten engeller mi? Evet, iki parçanın yerinde olmasıyla. Apidog CLI, herhangi bir başarısız iddiada sıfırdan farklı bir kodla çıkar, bu da TeamCity derlemesini başarısız kılar. Commit Status Publisher derleme özelliğini ekleyin ve Git ana bilgisayarınızın dal koruma kurallarında kontrolü zorunlu kılın, böylece birleştirme düğmesi paket geçene kadar devre dışı kalır.

Testleri çevrimiçi çalıştırmak ile dışa aktarılan bir dosyadan çalıştırmak arasındaki fark nedir? Proje kimliği ve erişim belirteciyle çevrimiçi çalıştırmak, Apidog'daki testlerinizin tek doğruluk kaynağı olduğu anlamına gelir; ekibin düzenlediği her şey CI'da çalışır. Dışa aktarılan bir dosyadan çalıştırmak, testleri deponuza kaydedilmiş bir sürüme bağlar. Çevrimiçi senkronize tutmak daha basittir; dışa aktarılan, kodla birlikte hareket eden testler sunar. Çoğu ekip çevrimiçi başlar.

Tüm regresyon paketini her push'ta değil, bir programa göre çalıştırabilir miyim? Evet. Hazırlık ortamına karşı gece (veya saatlik) çalıştırmak için derleme yapılandırmasına bir Zamanlama Tetikleyicisi ekleyin. Birçok ekip, her push'ta hızlı bir duman paketi ve gece programında tam regresyon paketi çalıştırır, böylece hızlı geri bildirim ve derin kapsama aynı dakikalar için rekabet etmez.

Özet

Her commit'te API testlerinizi çalıştıran bir TeamCity boru hattı, bozuk bir uç noktanın ekonomisini değiştirir. Hatayı bir müşteri bulmak yerine, derleme onu bulur; dalda, birleştirmeden önce, tam olarak başarısız olan iddia ve buna neden olan commit Testler sekmesinde gösterilir.

Kurulum, üç hareketli parçaya ayrılır: Apidog'da oluşturduğunuz gerçek iddialara sahip testler, bunları başsız bir şekilde çalıştıran ve başarısızlık durumunda sıfırdan farklı bir kodla çıkan tek bir `apidog run` komutu ve bu komutu çalıştıran, JUnit sonuçlarını ayrıştıran ve durumu Git ana bilgisayarınıza geri bildiren bir TeamCity derleme yapılandırması. Yerine oturduğunda, kapsayıcılığı boru hattı koduna dokunarak değil, Apidog'a senaryolar ekleyerek sürdürürsünüz.

İlk test paketinizi tasarlamak, CLI komutunu yerel olarak kanıtlamak ve ardından TeamCity'ye bırakmak için Apidog'u indirin. Bu noktadan itibaren, API'niz, birisinin çalıştırmayı hatırlayıp hatırlamadığına bakılmaksızın her bir commit'te aynı şekilde test edilir.