API Testleri İçin Postman Kullanmak

Merhabalar, profesyonel iş hayatımda genelde backend ile uğraştığım için en çok kullandığım araçların başında Postman geliyor. Postman, temelde bir rest client ve Chrome uzantısı olarak çalışmakta. API testleri ve tüketimi için son derece başarılı bir çok güzellik sağlıyor. Bu yazıda elimden geldiğince bunları anlatacağım.

Yazıya devam etmeden önce Postman ücretsiz bir tool olmakla birlikte üst düzey özelliklerine yer verdiği Jetpacks adında bir lisans satıyor. Bir kere $9.99 ödeyerek ömür boyu yükseltme alabiliyorsunuz. Peki nedir bu Jetpacks? Aslında Postman üzerinde bu yazıda anlatacağım bir çok şey için gerekli. Testler, pre-request script ve collection runner gibi bir çok güzel özelliği var.

Ben bu yazıda ücretsiz bir API olan openbeerdatabase.comı kullanacağım, sitesine girip üyelik oluşturduğunuz takdirde size public ve private olmak üzere 2 adet token verecek. Ancak bu tokenlar tamamen opsiyonel. Postman’i kurduktan sonra bir collection oluşturup adına “Open Beer Database” diyorum.

Öncelikle Postman üzerindeki “Environments” yapısına bakmamız lazım. Basitçe environments, birden fazla deploymentı olan (development, staging, production) API’lar için oluşturulan ön tanımlı değişkenler tutabildiğimiz yapılardır. Hemen bir environment tanımlayarak işe başlayalım.

Yukarıdaki ekran görüntüsünde de gördüğünüz gibi “No environment” yazan yere tıklayıp “Manage Environment” diyoruz.

Açılan ekrandan “Add” butonuna basıp yeni environment için isim veriyoruz.

Ben isim olarak “open-beer-database” dedim siz istediğinizi verebilirsiniz. Daha sonra “url” adında bir değişken tanımlayıp api adresini değer olarak veriyoruz.

Submit deyip kaydedelim. Environment içinde tanımladığımız değişkenleri request atarken requestin çeşitli yerlerinde kullanmak mümkün. Angularjs’le benzer bir ifade kullanarak {{url}} şeklinde erişilebiliyor.

Örneğin ben url değişkenimde ana adresi tuttum, sadece request atacağım pathler değişecek bu sayede. Hemen aşağıdaki ekran görüntüsünde kullanımını görebilirsiniz.

Url kısmında yazan ifadenin karşılığı aslında şöyle:

{{url}}/v1/beers.json = http://api.openbeerdatabase.com/v1/beers.json

Bu ana adres hiç değişmeyeceği için ben istediğim gibi üzerinde oynayabilirim.

Peki bu sizin geliştirdiğiniz bir API olsaydı ve siz hem lokalde hemde productiondaki halini test etmek isteseydiniz? Kolay, yeni bir environment ekleyip adına “open-beer-database-local” deyip “url” değişkenine “http://localhost:port” şeklinde değer vermeniz yeterli olacaktı. Tek bir collection üzerinden kısa bir seçim ile lokalinize ya da productiondaki API’ınıza request atabilirsiniz.

Artık requesti atalım ve cevabımıza bakalım.


Requestimizi attık, response aldık rahatladık. API’ımız çalışıyor, peki test yazmak istesek ? Let’s go.

Postman’in en sevdiğim taraflarından biride custom testler yazıp her requestin bu testleride çalıştırıyor olması. Siz her requesti önceden yazdığınız testleri geçiyor mu, yoksa hatalı mı bunu kolaylıkla görebiliyorsunuz. Testleri yazmak için temel düzeyde javascript yeterli.

Örneğin bu requestimiz için bir test yazalım. Test caselerimiz şunlar olsun:

  • Status code 200 mü ?
  • Response time 250ms nin altında mı ?
  • Response da biralar var mı ?
  • Response da hiç alman birası var mı ?

Temel düzeyde requesti attım, başarılı sonuç aldım mı, aldıysam performansı nasıl ve istediğim data, response içinde var mı diye 3 durumum var. Şimdide kodunu yazalım.

var data = JSON.parse(responseBody);
tests["Status code = 200"] = responseCode.code === 200;
tests["Response time < 250ms"] = responseTime < 250;
tests["Biralarım geldi mi ?"] = data.beers !== null;
tests["Alman birası ?"] = responseBody.has("German");

Testimizi yazdıktan sonra tekrar requesti atalım ve test sonuçlarına bakalım.

Gördüğünüz gibi 3 tane testi geçerken, response time biraz yüksek olduğu için fail etti. Biz 250ms den küçük olmasını istiyorduk ancak 334ms de response alabildik.


Testlerde tamam. Şimdi gelelim pre-request script dediğimiz kısma. Aslında adından anlaşılacağı gibi, bir request gönderilmeden önce yapılacak işlemleri kapsıyor. Örneğin ben requesti atmadan önce bir hesaplama yapıp hangi sayfayı ve bir sayfada kaç tane item gösterileceğini belirleyebilirim.

postman.setEnvironmentVariable("page", "1");
postman.setEnvironmentVariable("per_page", "10");

Bu kod aslında en başta environment içinde url tanımlamak ile aynı işi yapıyor. Pre-request script içine bu kodu yazıp requesti gönderdiğimizde environment içinde url haricinde page ve per_page isminde iki değişkenin daha oluşturulduğunu görebilirsiniz.

Paging kullanarak response time ı düşürdük bakalım testlerimiz yeni requestimiz ile ne alemde ?

Testlerimizin hepsi geçti tebrikler. Peki bu pre-request script neye yarar ? Örneğin bir API geliştiriyorsunuz ve bir token mekanizmanız var. Aldığınız token 30 dakikada bir düşüyor diyelim. Test ederken developmenta da devam ettiğiniz için bir endpointi yazıp test ettikten sonra bir sonrakini geliştirip test edene kadar token geçersiz olacağından yeni bir token daha almanız gerekecek. Bu durumda token gerektiren her requestin başına token requesti pre-request script olarak eklerseniz sorun ortada kalkar. Şöyle ki;

Request atacağım getFalanFilan endpointi header da bir Authorization değeri istiyor. Bende requesti atmadan önce token almak için gerekli olan bilgileri ve requesti pre-request script içine yazdım. Request gitmeden önce benim token requestim çalışacak, response başarılı döndü ise ben “authToken” isimli değişkenime “Bearer UzunBirTokenDeğeriFalanFilanZartZurt” değerini atayıp asıl requestim olan getFalanFilan ı çalıştıracağım. Hepsi bu kadar.


Testleri yazdık, pre-request scriptlerde tamam, şimdi sıra geldi collection runner’a. Collection runner, bir collectiondaki endpointleri sizin verdiğiniz değişkenler ile n kere çalıştırmaya yarıyor.

Yeni bir endpoint ekliyorum : {{url}}/v1/beers/{{id}}.json

Bu request, url ve id değişkenlerini dışarıdan alıyor ve benim verdiğim id ye sahip biranın detaylarını getiriyor.

Ben bunu 20 farklı id ile denemek istersem tek tek elimle id değiştirmekle uğraşmayacağım heralde değil mi ? Collection runner işte bize bunu sağlıyor. Hemen bir json dosyası hazırlıyorum kendime, içinde url ve id değişkenleri olan bir array olmalı bu.

[
{
"url": "http://api.openbeerdatabase.com",
"id": "1"
},
{
"url": "http://api.openbeerdatabase.com",
"id": "2"
},
{
"url": "http://api.openbeerdatabase.com",
"id": "3"
},
{
"url": "http://api.openbeerdatabase.com",
"id": "4"
},
{
"url": "http://api.openbeerdatabase.com",
"id": "5"
}
]

Json dizimi oluşturdum, bunu “collection-runner.json” ismi ile bilgisayarımda kaydediyorum herhangi bir yere. 1 den 5 e kadar olan id li biraları collection runner a 5 kere sokacağız.

Collection olarak Open Beer Database seçtim, environment olarak open-beer-database seçtim. Bu arada eğer json array içinde, environment içinde olan bütün değişkenleri tanımlarsanız collection runner ekranından environment seçmenize gerek kalmaz. 5 kere ve 50ms delay ile çalıştırılmasını istiyorum, data olarak kaydettiğim collection-runner.json dosyasını seçip data file type olarak JSON seçip Start diyorum.

Collection runner istediğimiz gibi, bizim verdiğimiz datalar ile her endpointi 50ms delay ile 5 kere çalıştırdı. Buna göre önceden yazmış olduğumuz testlerin durumlarını bize gösterdi. Örneğin Beers requesti 5 te 5 başarılı olmuş, sadece 5 te 1'i 250ms den geç response almış, 5 te 5 beers arrayi dolu gelmiş ve 5 te 5 alman birisi mutlaka response da gelmiş.

Diğer requestte ise yukarıdaki ile aynı ancak tek bir id verip o id ye ait birayı getirdiğimiz için oldukça hızlı dönmüş ve hepsi 250ms altında. Ancak verilen id lerden sadece 1 tanesi alman birası imiş.

Biraz daha detaylı inceleyelim.

Sadece ilk gönderilen request 250ms den daha uzun sürmüş.

Sadece ilk gönderilen yani id’si 1 olan bira alman birası imiş.


Tanrı Postman’i korusun ve yüceltsin. Amen.

Like what you read? Give Melih Mucuk a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.