Otomatik bir test betiği yazmak kolaydır. Altı ay sonra bile yerini koruyan bir betik yazmak ise zor kısımdır. Pek çok test betiği yazılır, bir kez yeşil çalışır ve sonra yavaşça çürür, ilgisiz değişikliklerde bozulur, anlamlı hiçbir şeyi doğrulamadan kalır ve ekibi kırmızı derlemeleri görmezden gelmeye alıştırır. İyi bir test betiği hassas, izole edilmiş ve dayanıklıdır.
Bu rehber, otomatik bir test betiğinin ne olduğunu, onu güvenilir kılan yapıyı, API test betiği yazmanın iki yolunu ve Apidog'da adım adım oluşturmayı kapsar.
Otomatik test betiği nedir
Otomatik bir test betiği, yazılımınızın bir bölümünü çalıştıran ve sonucu kontrol eden, adımları bir insanın çalıştırması gerekmeyen, tanımlanmış, tekrarlanabilir bir talimatlar dizisidir. Betik bir girdi gönderir, bir eylem gerçekleştirir ve sonucu bir beklentiyle karşılaştırır. Eşleşirse geçer. Eşleşmezse başarısız olur ve nedenini rapor eder.
Bir test betiği, bir test durumunun yürütülebilir halidir. Test durumu, amacı, girdiyi, eylemi ve beklenen sonucu insan dilinde açıklar. Betik, bu amacı, her commit'te bir makinenin çalıştırdığı bir şeye dönüştürür. Bir test durumu bir betik haline gelebilir; bir test senaryosu genellikle birbirine zincirlenmiş birkaç betik haline gelir.
Otomatik bir test betiğinin tüm değeri, her zaman aynı şekilde çalışmasıdır. Bu, ancak betik deterministik olacak şekilde yazılmışsa geçerlidir. Diğer betiklerin çalışma sırasına veya önceki bir çalıştırmanın geride bıraktığı verilere bağımlı olan bir betik, güvenilir bir otomasyon değildir; geçici bir yükümlülüktür.
Güvenilir bir test betiğinin yapısı
Neredeyse her iyi yazılmış test betiği, herhangi bir dilde veya araçta, aynı dört bölümden oluşan yapıyı izler. Genellikle Düzenle-Uygula-Doğrula (Arrange-Act-Assert) olarak adlandırılır ve temizlik de eklenir.
Düzenle (Arrange). Testin ihtiyaç duyduğu her şeyi kurun: girdi verileri, kimlik doğrulama, tüm ön koşullar. Betik, var olduğunu varsaymak yerine kendi durumunu oluşturmalıdır. Testin bir kullanıcıya ihtiyacı varsa, veritabanında ne olursa olsun değil, bir tane oluşturur veya bilinen bir fikstür kullanır.
Uygula (Act). Test edilen tek eylemi gerçekleştirin. İyi bir betik tek bir davranışı test eder. Bir istek göndermek, bir fonksiyon çağırmak, bir olayı tetiklemek, işte bu eylemdir ve betik başına tam olarak bir tane olmalıdır.
Doğrula (Assert). Sonucu beklentilere göre kontrol edin. Bu, ekiplerin yeterince yatırım yapmadığı kısımdır. Sadece "hata oluşmadı" veya "durum 200'dü" şeklinde doğrulayan bir betik, neredeyse hiçbir şeyi test etmez. Güçlü doğrulamalar gerçek değerleri kontrol eder: yanıt gövdesi, şema, yan etkiler, zamanlama.
Temizle (Cleanup). Betiğin oluşturduğu her şeyi geri alın, böylece temiz bir başlangıçtan tekrar çalışabilir. Test verilerini geride bırakan bir betik, sonunda kendisiyle veya başka bir betikle çakışacaktır.
Üç alışkanlık, dayanıklı betikleri kırılgan olanlardan ayırır. Betik başına bir şeyi test edin, böylece bir hatanın tek bir bariz nedeni olur. Betikleri bağımsız tutun, böylece herhangi bir sırada çalışabilirler. Ve asla üretilen kimlikler veya zaman damgaları gibi değişken veriler üzerinde değil, istikrarlı değerler üzerinde doğrulama yapın, çünkü bu tür veriler bir betiğin gerçek bir neden olmaksızın başarısız olmasına neden olur.
API test betikleri yazmanın iki yolu
Özellikle API testi için iki yaygın yaklaşım vardır ve bunlar farklı ekiplere uygundur.
Kod öncelikli yaklaşım, test betiklerini genel amaçlı bir dilde yazar. Python'da bu, pytest gibi bir çerçeve ve bir HTTP kütüphanesi anlamına gelir; JavaScript'te bir test çalıştırıcı ve fetch. İsteği, doğrulamaları ve kurulumu gerçek kod olarak yazarsınız ve betikler uygulamanızla birlikte deponuzda bulunur.
Bu yaklaşım tam programatik kontrol sağlar. Karmaşık mantık, özel fikstürler ve alışılmadık doğrulamaların hepsi sadece koddur. Maliyeti ise, her betiğin sizin yazdığınız ve sürdürdüğünüz bir kod olması, ekibin dil becerilerine ihtiyaç duyması ve birçok şablon, kimlik doğrulama, istek oluşturma, yanıt ayrıştırma gibi işlemlerin betikler arasında yeniden yazılmasıdır. Testlerin kodla birlikte versiyonlanmasını isteyen ve bu sürdürmeyi üstlenmekten rahat olan mühendislik ekiplerine uyar.
Görsel yaklaşım, test betiğini özel bir API test aracında oluşturur. İstekleri tanımlar, tıklayarak doğrulamalar ekler ve istekleri senaryolar halinde zincirleyerek, yaygın durumlar için betik kodu yazmadan veya sürdürmeden ilerlersiniz. Apidog gibi araçlar bu yolu izler.
Bu yaklaşım, şablonları ortadan kaldırır ve betikleri sadece dili bilenler değil, ekipteki herkes tarafından okunabilir hale getirir. Görsel oluşturucunun ifade edemediği nadir mantık için yine de özel koda başvurursunuz. Karma ekiplere, QA liderliğindeki testlere ve bir betik projesi eklemeden hızlıca çalışan bir test paketi isteyen herkese uyar.
İkisi de yanlış değildir. Belirleyici soru, betikleri kimin sürdürdüğü ve uygulama deposunda yer alıp almayacaklarıdır. Çoğu API testi için görsel yaklaşım, daha az bakım gerektirerek güvenilir bir paketi daha hızlı çalıştırır.
Apidog'da otomatik bir API test betiği yazma
Dayanıklı bir API test betiğini görsel olarak oluşturmak için tam akış aşağıdadır.
Adım 1: İsteği tanımlayın. Uç noktayı bir OpenAPI dosyasından Apidog'a getirin veya doğrudan tanımlayın. Bu, Düzenleme (Arrange) adımıdır; istek yöntemini, yolunu, başlıklarını ve gövdesini taşır.
Adım 2: Test verilerini ekleyin. Test ettiğiniz durum için girdi yükünü ayarlayın. Birçok girdiyi tek bir betikle kapsamak için bir CSV veya JSON dosyası ekleyin, böylece betik her satır için bir kez çalışır; veri odaklı test, birbirine yakın bir düzine betiği tek bir betikle değiştirir.
Adım 3: Doğrulamaları yazın. Burası çekirdek kısımdır. Görsel kontroller ekleyin: durum beklenen koda eşit mi, ana gövde alanları mevcut mu ve doğru değerlere sahip mi, yanıt şemaya uygun mu, yanıt süresi bütçe içinde mi. Negatif durumlar için sadece hata kodunu değil, hata yapısını da doğrulayın. Değişken verileri doğrulama dürtüsüne karşı koyun.
Adım 4: İstekleri bir senaryoya zincirleyin. Gerçek iş akışları birkaç çağrıyı kapsar. Oturum açan, bir kaynak oluşturan, onu geri okuyan ve silen, değerleri bir adımdan diğerine geçiren bir senaryo oluşturun. Her adım bir betiktir; birlikte eksiksiz bir akışı test ederler.
Adım 5: Yalnızca gerektiğinde özel betik mantığı ekleyin. Görsel doğrulamaların ifade edemediği kontroller, koşullu mantık, hesaplanmış değerler, istekler arası karşılaştırmalar için bir JavaScript ön veya son işlemcisi ekleyin. Bunu minimumda tutun; çoğu betiğin buna asla ihtiyacı yoktur.
Adım 6: Çalıştırın ve raporu okuyun. Senaryoyu yürütün. Apidog her betiği çalıştırır, her doğrulamayı değerlendirir ve başarısız olan kontrolü beklenen ve gerçek değerlerle yan yana raporlar.
Adım 7: Çalıştırmayı otomatikleştirin. Senaryoyu her commit'te çalışacak şekilde CI/CD'ye bağlayın. Yalnızca biri hatırladığında çalışan bir test betiği aslında otomatik değildir. İlk senaryonuzu oluşturmak için Apidog'u indirin.
Test betiklerini sağlıklı tutmak
Bir test paketi yaşayan bir varlıktır. Yayınlandığında mükemmel olan betikler, API değiştikçe güncelliğini yitirir. Üç uygulama bir paketi güvenilir tutar.
Betikleri API ile birlikte güncelleyin, ondan sonra değil. Bir uç noktanın sözleşmesi değiştiğinde, betik de aynı commit'te değişmelidir. Eski bir şemayı doğrulayan bir betik yanlış nedenle başarısız olur ve diğer tüm betiklere olan güveni zayıflatır.
Geçici hatalı (flaky) betikleri gerçek hata olarak ele alın. Çoğu zaman geçen bir betik, hiç olmamasından daha kötüdür, çünkü ekibe kırmızının bozuk anlamına gelmediğini öğretir. Nedeni bulun, genellikle paylaşılan durum veya bir zamanlama varsayımıdır ve düzeltin.
Betikleri üretim kodu gibi gözden geçirin. Zayıf doğrulamalara sahip, yalnızca 200 kontrolü yapan bir betik, neredeyse hiçbir şeyi test etmezken yeşil görünür ve güvenli hissettirir. İkinci bir okuyucu bunu yakalayacaktır.
Sıkça sorulan sorular
Bir test durumu ile bir test betiği arasındaki fark nedir? Bir test durumu, amacı insan dilinde, girdiyi, eylemi, beklenen sonucu açıklar. Bir test betiği, bir makinenin çalıştırdığı yürütülebilir versiyondur. Durum plandır; betik ise uygulamadır.
Otomatik test betikleri yazmak için kodlama bilmem gerekiyor mu? Görsel bir araçla API testi için gerekmez. Apidog'da istekleri, doğrulamaları ve senaryoları tıklayarak oluşturur, yalnızca alışılmadık mantık için kod yazarsınız. Kod öncelikli çerçeveler dil becerileri gerektirir.
Test betiklerim neden sürekli bozuluyor? Yaygın nedenler, değişken veriler üzerinde doğrulama yapılması, betiklerin birbirlerinin durumuna bağlı olması ve API değiştiğinde betiklerin güncellenmemesidir. Test verilerini izole edin, betikleri bağımsız tutun ve sözleşmeyle birlikte güncelleyin.
Bir test betiği kaç doğrulama içermelidir? Sonucu gerçekten doğrulamak için yeterli sayıda; tipik olarak durum, ana gövde alanları, şema ve zamanlama. Tek bir durum kodu doğrulaması çok azdır; yanıt yanlış olsa bile geçer.
Test betikleri uygulama deposunda mı yer almalı? Kod öncelikli bir yaklaşımla, genellikle evet, böylece testler kodla birlikte versiyonlanır. Görsel bir araçla, betikler test platformunda yaşar ve bunun yerine API tanımına senkronize olur. Her ikisi de çalışır; tutarlılık seçimden daha önemlidir.
API oluşturulmadan önce test betiklerini nasıl yazarım? API tasarımına göre yazın. Bir OpenAPI spesifikasyonunuz varsa, ondan istekleri ve doğrulamaları tanımlayabilir, ardından gerçek uç nokta oluşana kadar bunları bir sahte sunucuya karşı çalıştırabilirsiniz. Uygulama devreye girdiği anda betikler hazır olur.
Bir test betiği ile bir test paketi arasındaki fark nedir? Bir test betiği tek bir kontrolü çalıştırır. Bir test paketi, genellikle bir API'nin veya özelliğin tamamını kapsayan, birlikte çalıştırılmak üzere gruplandırılmış bir betik koleksiyonudur. Paketler, büyüyen bir betik kümesini düzenli tutar ve tek bir komutla geniş kapsama alanı çalıştırmanıza olanak tanır.
Otomatik bir test betiği ne kadar uzun olmalıdır? Düzenle, uygula, doğrula, temizle olmak üzere dört bölümü hala yaparken olabildiğince kısa. Bir betik uzunsa, genellikle birden fazla şeyi test ediyordur ve ayrılmalıdır. Betik başına tek bir davranış, hataların teşhisini kolaylaştırır.