Cuma günü saat 16.00'da bir dağıtım yapıldı. Birim testleri yeşildi, konteyner oluşturuldu, dağıtım hatasız tamamlandı. Ardından destek kuyruğu dolmaya başladı: ödeme sistemi 500'lü hatalar veriyordu. Hata, test edilen kodda hiç olmadı. Hata, iki hizmetin birbiriyle nasıl iletişim kurduğundaydı ve ardışık düzendeki hiçbir test bu iletişimi hiç test etmemişti.
İşte DevOps'taki test otomasyonunun kapatması gereken boşluk bu, ve çoğu ekibin yeterince yatırım yapmadığı kısım API katmanıdır. Birim testleri bir fonksiyonun izole bir şekilde çalıştığını kanıtlar. Uçtan uca kullanıcı arayüzü testleri, bir tarayıcının bir akışta yavaş ve kararsız bir şekilde tıklayabileceğini kanıtlar. Hizmetleriniz arasındaki sözleşme, yani üretimde gerçekten bozulan şey, ortada yer alır ve genellikle kontrol edilmez. API testleri tam olarak orada bulunur.
DevOps'ta test otomasyonu aslında ne anlama geliyor
DevOps bir döngüdür, bir çizgi değil. Planla, kodla, oluştur, test et, yayınla, dağıt, işlet, izle, sonra tekrar planla. DevOps'ta test otomasyonu, testlerin, sorunları en ucuz şekilde yakaladıkları döngü noktalarında otomatik olarak çalışması anlamına gelir; birinin bir yayın öncesi bir kez manuel olarak çalıştırdığı bir kapı olmak yerine.
Bunun arkasındaki ilke 'sola kaydırma'dır: testleri daha erken, bir geliştiricinin değişikliği yazdığı ana daha yakın hareket ettirin. Bir çekme isteğinde yakalanan bir hatanın düzeltilmesi dakikalar sürer. Aynı hatanın üretimde yakalanması bir geri alma, bir olay kanalı ve bir otopsi maliyeti doğurur. Otomasyon, sola kaydırmayı mümkün kılar, çünkü bir insan her taahhütte bir regresyon paketini manuel olarak yeniden çalıştıramaz, ancak bir ardışık düzen çalıştırabilir.
Hata, "test otomasyonunu" tek bir kova olarak ele almaktır. Test piramidi bunu katmanlara ayırır ve her katman farklı bir soruyu yanıtlar:
- Birim testleri tek bir fonksiyonun doğru değeri döndürüp döndürmediğini sorar. Hızlı ve çok sayıdadırlar.
- API ve entegrasyon testleri hizmetlerinizin doğru yanıtlar üretip üretmediğini ve birbirleriyle doğru konuşup konuşmadığını sorar. Bunlardan daha azı vardır, ancak her biri daha geniş bir alanı kapsar.
- Uçtan uca testler tüm sistemin kullanıcının bakış açısından çalışıp çalışmadığını sorar. Yavaş, kırılgan ve az sayıda tutulmaya değerdir.
API testleri verimli orta kısımda yer alır. Dakikalar değil, saniyeler içinde çalışırlar. Render edilmiş bir kullanıcı arayüzüne bağlı değillerdir, bu yüzden bir düğme hareket ettiğinde bozulmazlar. Ve diğer hizmetlerinizin ve müşterilerinizin gerçekten bağlı olduğu yüzeyi test ederler. Bu yüzden, bir DevOps ardışık düzeninde, API testleri regresyon yakalama yükünün diğer tüm katmanlardan daha fazlasını taşır. Uygulamanın temelleri için, API test otomasyonu, nerede çalışacağından endişelenmeden önce neyi ve neden iddia edeceğinizi kapsar.
DevOps yaşam döngüsü, aşama aşama ve API testlerinin yeri
İşte pratik harita. Her ekip her aşamada API testlerine ihtiyaç duymaz, ancak seçenekleri bilmek, her şeyi tek bir devasa dağıtım öncesi işe atmak yerine bilinçli seçimler yapmanızı sağlar.
Geliştirme sırasında: yerel ve ön taahhüt
Bir değişiklik CI'ya ulaşmadan önce, bir geliştirici ilgili API testlerini yerel veya geliştirme ortamına karşı çalıştırabilmelidir. Sahip olduğunuz en hızlı geri bildirim döngüsü budur. Burada bozuk bir yanıt şekli yakalamak, bozuk kodun hiçbir zaman gönderilmediği anlamına gelir.
Pratikte bu, daha sonra CI'da çalıştıracağınız senaryonun aynısıdır, sadece yerel bir ortama yönlendirilmiştir. Bir kez oluşturursunuz. Daha önce hiç yazmadıysanız, Apidog ile test senaryoları nasıl yazılır, istekleri zincirleme ve bir yanıttan diğerine değer çekme konularını adım adım açıklar.
Çekme isteklerinde: birleştirme kapısı
Burası API testleri için en yüksek değerli yerdir ve ekiplerin çoğu zaman atladığı yerdir. Bir çekme isteği açıldığında, ardışık düzen hizmeti başlatır, API senaryolarınızı ona karşı çalıştırır ve bir durum kontrolü olarak geçip geçmediğini raporlar. Başarısız bir kontrol birleştirmeyi engeller.
Bunun önemli olmasının nedeni: bir hatanın maliyeti ne kadar uzağa giderse o kadar keskin bir şekilde artar. Bir PR'daki başarısız bir iddia, değişikliği hala aklında taze tutan yazar için beş dakikalık bir düzeltmedir. Bir hafta sonra hazırlık ortamında bulunan aynı hata bir arkeoloji projesidir. API testlerini PR kapısına koymak, en fazla hatayı sola kaydıran tek değişikliktir.
Derlemeden sonra, yayınlanmadan önce: entegrasyon ve sözleşme kontrolleri
Yapılandırma tamamlanıp bir hazırlık veya entegrasyon ortamına dağıtıldıktan sonra daha geniş bir test paketi çalıştırın. Burası gerçek bağlantıları test ettiğiniz yerdir: ödeme hizmeti hala sipariş hizmetinin istek gövdesini kabul ediyor mu, sayfalama hala istemcinizin okuduğu alanı döndürüyor mu, bir hizmet tarafından verilen bir kimlik doğrulama belirteci başka bir hizmet tarafından kabul ediliyor mu.
Bu aşama aynı zamanda sözleşme düşüncesinin karşılığını verdiği yerdir. Yerel olarak geçerli olan bir değişiklik, yine de aşağı akıştaki bir tüketiciyi bozabilir. Entegre bir ortama karşı tüm senaryo setini çalıştırmak, birim testlerinin yapısal olarak göremediği hizmetler arası bozulmaları yakalar. Desenler daha geniş API test otomasyonu pratiğinden aktarılır.
Dağıtım zamanı: duman testleri
Bir dağıtım, yayılma tamamlandığında bitmiş sayılmaz. Yeni sürümün trafiği gerçekten doğru şekilde sunduğuna dair kanıtınız olduğunda tamamlanmış olur. Bir duman testi, dağıtımdan hemen sonra kritik yolları vuran küçük, hızlı bir senaryodur: bir kullanıcı kimlik doğrulaması yapabilir mi, verilerini okuyabilir mi, sağlık açısından kritik uç nokta doğru şekille 200 döndürüyor mu.
Bu test paketini küçük ve hızlı tutun. İşi kapsayıcılık değil, bir geçiş veya geçiş yok sinyalidir. Eğer başarısız olursa, otomatik olarak geri alırsınız. Tek bir ortam bayrağını değiştirerek aynı senaryoyu üretim ortamına karşı çalıştırın, korunacak yinelenen bir test yoktur.
Üretimde: sürekli izleme
Dağıtımdan sonra döngü durmaz. CI'da çalıştırdığınız aynı API senaryoları, sentetik izleme olarak üretime karşı belirli bir zaman çizelgesine göre çalışabilir, bir müşteriden önce bozulan bir üçüncü taraf bağımlılığını veya süresi dolmuş bir sertifikayı yakalayabilir. Bir test ile bir izleyici arasındaki çizgi çoğunlukla çalıştığı zaman çizelgesidir. API izleme, geçen testleri bir üretim erken uyarı sistemine dönüştürmeyi kapsar.
Beş aşamanın tamamında faydalı bir genel kural: üretime ne kadar yakınsa, test paketi o kadar küçük ve hızlı olmalıdır. PR'larda ve entegrasyonda geniş kapsama; dağıtım ve izlemede ince, acımasız bir duman testi paketi.
API katmanı neden ardışık düzende yerini hak ediyor
API testlerinin neden kullanıcı arayüzü testlerine daha fazla ağırlık yüklemek yerine ana gayrimenkulü hak ettiğini somutlaştırmak faydalıdır.
Hızlıdırlar. Bir API senaryosu HTTP ile doğrudan konuşur. Başlatılacak bir tarayıcı, beklenecek bir DOM, yavaş bir renderda kararsızlaşan başsız Chrome yoktur. Bir düzine uç noktayı çalıştıran bir senaryo saniyeler içinde biter; bu da insanların on dakikalık bir işi görmezden gelmeyi öğrenmeden her taahhütte çalıştırmanıza olanak tanır.
Kararlıdırlar. Kullanıcı arayüzü testleri, bir sınıf adı değiştiğinde veya bir öğe geç bir karede yeniden oluşturulduğunda bozulur. API testleri yalnızca gerçek sözleşme değiştiğinde bozulur, ki tam da bunu bilmek istediğiniz zamandır. Daha az kararsızlık, insanların kırmızı bir yapıya güvenmesi anlamına gelir ve insanların güvendiği bir yapı, herhangi bir şeyi engelleyen tek yapıdır.
Entegre olanı test ederler. Mobil uygulamanız, iş ortağı entegrasyonlarınız, kendi mikro hizmetleriniz hepsi API sözleşmesine bağlıdır, CSS'nize değil. Bu sözleşme sessizce değiştiğinde, her tüketici aynı anda bozulur. API testleri bunu yakalayan katmandır.
Bu yüzden ardışık düzen sorunu aslında bir API sorunudur. Kapsamlı bir birim test paketiniz ve güzel bir kullanıcı arayüzü paketiniz olabilir ve yine de Cuma öğleden sonraki ödeme hatasını yayınlayabilirsiniz, çünkü hiçbir katman hizmetlerin buluştuğu yeri izlemiyordu.
API testlerini Apidog CLI ile ardışık düzene bağlamak
Mekanikler önemlidir, çünkü var olan ancak otomatik olarak çalışmayan bir test hiçbir şeyi yakalamaz. Her CI sisteminde desen aynıdır: bir çalıştırıcı kurun, testlerinizi ona yönlendirin, yapılandırmanın geçip geçmediğine çıkış kodunun karar vermesini sağlayın.
Apidog ile testlerinizi kod olarak yeniden yazmazsınız. Senaryoyu uygulamada bir kez oluşturursunuz, ardından Apidog CLI aynı senaryoyu başsız olarak çalıştırır. CLI bir npm paketidir, bu nedenle Node.js kurulu herhangi bir CI çalıştırıcısı bunu kullanabilir.
npm install -g apidog-cli
Ardından bir senaryo çalıştırın. Apidog'daki test senaryosunun CI/CD sekmesinde erişim belirtecini oluşturur ve senaryo ile ortam kimliklerini bulursunuz, bu size kopyalamanız için tam komutu oluşturur:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 605067 \
-e 1629989 \
-r cli
Burada birkaç şey gerçek iş yapıyor. `-t` bayrağı senaryoyu kimliğe göre adlandırır; tüm bir klasörü çalıştırmak için bunu `-f` ile veya küratörlü bir test paketini tek bir iş olarak çalıştırmak için `--test-suite` ile değiştirin. `-e` bayrağı ortamı seçer, bu sayede aynı senaryo bir PR'yi hazırlık ortamına karşı ve üretim ortamına karşı duman testlerini yinelenen bir teste gerek kalmadan engelleyebilir. `-r` bayrağı raporlayıcıları seçer; `cli` günlüğe yazdırır ve `junit` CI panonuzun bir test raporu olarak oluşturabileceği XML'i yayar.
Bunu bir geçit yapan kısım çıkış kodudur. Bir senaryodaki her iddia geçtiğinde, `apidog run` `0` ile çıkar. Herhangi bir şey başarısız olduğunda, sıfır olmayan bir kodla çıkar. CI sisteminiz bu kodu okur, adımı başarısız olarak işaretler ve birleştirme veya dağıtımı engeller. Ayrı bir geçit yapılandırmasına gerek yoktur; çıkış kodu geçittir. Sürümünüz için tüm bayrak yüzeyini görmek için `apidog run --help` komutunu çalıştırın.
İşte PR-gate aşaması GitHub Actions'a bağlanmış hali:
name: API Tests
on: [pull_request]
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 scenarios
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t 605067 \
-e 1629989 \
-r cli,junit
Belirteç, depo sırlarında yaşar ve `env:` aracılığıyla adıma ulaşır, asla sabit kodlanmaz. Aynı blok, yalnızca gerçek bağımlılık Node olduğu için o platformun sözdizimiyle birlikte GitLab CI, Jenkins, CircleCI veya Azure Pipelines'a düşer. Platforma özel kılavuzlar ayrıntıları kapsar: GitHub Actions'ta API testlerini otomatikleştirme ve Apidog testlerini Jenkins ile entegre etme.
Dağıtım zamanı duman testi aşaması için komut neredeyse hiç değişmez. Komutu üretim ortamı kimliğine yönlendirir ve senaryoyu küçük tutarsınız:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e $PROD_ENV_ID -r cli
Bir senaryo, bir ortam değişimi, iki iş. İşte testleri bir kez yazıp yaşam döngüsü boyunca çalıştırmanın tüm cazibesi bu.
Kapıyı sessizce yenen yaygın hatalar
Bir ardışık düzen tamamen otomatik görünse bile hiçbir şey yakalamayabilir. Bunlara dikkat edin.
Çıkış kodunu yutmak. Birisi test komutunu bir kabuk ardışık düzenine sarar veya "yapılandırmanın bozulmasını engellemek" için `|| true` ekler. Bu, aynı zamanda herhangi bir şey yakalamasını da engeller. Yapılandırma sonsuza kadar yeşil kalır. Çalıştırıcının sıfır olmayan çıkışını asla maskelemeyin; o çıkış tüm meselenin özüdür.
Yalnızca doğru senaryoyu test etmek. `200 OK`'i onaylayan ve orada duran bir senaryo, önemli olan bozulmaları kaçırır. Yanıt gövdesi şeklini, alan türlerini, hatalı girişler için hata yanıtlarını iddia edin. API iddiaları, bir durum kodundan fazlasını doğrulamayı kapsar.
Tek bir devasa dağıtım öncesi iş. Her testi yayınlanmadan hemen önce tek bir aşamaya sıkıştırmak 'sola kaydırma' ilkesini bozar. Bozuk bir sözleşmeyi PR'da değil, gönderimden dakikalar önce öğrenirsiniz. Test paketini aşamalara yayın: PR'larda geniş, dağıtımda ince.
Paylaşılan değiştirilebilir bir ortama karşı test yapmak. İki ardışık düzen aynı veritabanına çarptığında, bir çalıştırmanın yazımları diğerinin okumalarını zehirler ve güveni sarsan kararsız hatalar alırsınız. Yalıtılmış ortamlar kullanın veya kontrol edemediğiniz bağımlılıkların yerine geçmek için API mocklama kullanın, böylece bir üçüncü tarafın kesintisi yapınızı kızartmasın.
Başarısızlık raporunu unutmak. Raporunuz yalnızca testler geçtiğinde yüklenirse, ihtiyacınız olduğu tek seferde raporu asla göremezsiniz. Yapılandırma yüklemesini başarısızlık durumunda bile çalışacak şekilde ayarlayın.
Sıkça Sorulan Sorular
API testleri DevOps ardışık düzeninde nerede çalışmalıdır?
Minimum olarak, çekme isteklerinde bir birleştirme kapısı olarak, çünkü bu, en düşük maliyetle en fazla hatayı yakalar. İdeal olarak, sözleşme kontrolleri için entegre bir ortama karşı derlemeden sonra ve dağıtımdan hemen sonra küçük bir duman testi paketi olarak da çalıştırılmalıdır. Aynı Apidog senaryosu her aşamada çalışır; yalnızca ortam bayrağını değiştirirsiniz. Postman olmadan Apidog kullanan ekipler aynı hazırlık aşamasını izler.
API test otomasyonu ile CI/CD arasındaki fark nedir?
CI/CD, kodunuzu otomatik olarak derleyen, test eden ve gönderen ardışık düzendir. API test otomasyonu, bu ardışık düzen içinde çalışan bir test türüdür. CI/CD bir taşıma bandıdır; otomatik API testleri ise üzerinde bir kalite istasyonudur. CI/CD terimi belirsizse, CI/CD nedir temel bilgileri kapsar.
CI'da çalıştırmak için API testlerimi kod olarak yeniden yazmam gerekiyor mu?
Apidog ile hayır. Test senaryosunu uygulamada görsel olarak oluşturursunuz ve Apidog CLI aynı senaryoyu başsız olarak çalıştırır. CLI bir npm paketidir, bu nedenle Node.js kurulu herhangi bir CI çalıştırıcısı bunu tek bir komutla yürütebilir.
API testleri bir derlemeyi nasıl başarısız kılar?
Çıkış kodu aracılığıyla. Bir senaryodaki her iddia geçtiğinde, çalıştırıcı `0` ile çıkar. Herhangi bir iddia başarısız olduğunda, sıfır olmayan bir kodla çıkar. CI sistemi bu kodu okur, adımı başarısız olarak işaretler ve birleştirme veya dağıtımı engeller. Ayrı bir geçit yapılandırmasına gerek yoktur.
Performans testleri aynı ardışık düzende çalışmalı mı?
Her PR'da işlevsel API testlerini tutun ve daha ağır yük ve performans testlerini ayrı bir zaman çizelgesinde, örneğin her gece, çalıştırın. Performans çalıştırmaları daha uzun sürer ve kararlı bir ortama ihtiyaç duyar, bu nedenle her taahhüte bağlamak, taahhüt başına çok fazla sinyal eklemeden geri bildirimi yavaşlatır.
İlk API testinizi nereye koymalısınız?
DevOps'ta test otomasyonu bir kez inşa ettiğiniz tek bir geçit değildir. API testleri döngü boyunca bilinçli olarak yerleştirilir: hızlı geri bildirim için geliştiricinin makinesinde, en çok hatayı yakalayan birleştirme kapısı olarak çekme isteğinde, sözleşme kontrolleri için derlemeden sonra, dağıtım zamanında bir duman sinyali olarak ve üretimde bir izleyici olarak. API katmanı en çok ardışık düzen alanını kazanır çünkü hızlı, kararlı ve sistemlerin gerçekten bozulduğu dikişi test eder.
API testleriniz hala birinin manuel olarak çalıştırdığı tıklanabilir adımlar olarak yaşıyorsa, kapatılması gereken boşluk birleştirme kapısıdır. Apidog'u indirin, bir senaryo oluşturun, CI/CD sekmesinden `apidog run` komutunu kopyalayın ve yukarıdaki GitHub Actions bloğunu yapıştırın. Öğleden sonra sonunda bozuk birleştirmeleri engelleyen API testleriniz olacak ve Cuma günü dağıtım hatası destek kuyruğunuzda değil, bir çekme isteğinde kırmızıya dönecek.