Herkese merhaba, bu yazımda Postman Komut dosyası üzerinden yer yer karşılaştığım ve çözüme kavuşturduğum bazı püf noktalarını sizlerle paylaşmaya gayret edeceğim.
Hazırsak başlayalım;
Flow Control - Akış Kontrolü
Depomuzdaki bazı testler kuru veya statik kontroller gerçekleştirir. Bir istek gönderirler, yanıt alırlar ve bunu altın bir sonuçla eşleştirirler. Bu testler birbirinden bağımsızdır. Aynı API'yi paylaştıkları için tek bir koleksiyon altında bir araya toplanmış olabilirler, ancak bir isteğin onaylanmasında başarısız olmak, diğerlerinin de çalışamayacağı anlamına gelmez. Öte yandan, bazı testler, bir talebin yanıtından elde edilen verilerin sonraki istek tarafından kullanıldığı çoklu adımlardan (requests) oluşan bir akış olarak yazılır. Böyle bir koleksiyondaki bir adım, önceki adımına bağlıdır. Bu nedenle, bir adımda başarısız olduğunda, koşucu bir sonrakine devam etmemelidir.
pm.test(`${pm.info.requestName} - Check response.`, function() {
postman.setNextRequest(null);
pm.expect(pm.response).to.have.property('code', 200);
const body = pm.response.json();
pm.environment.set('data_for_next_request', body);
postman.setNextRequest();
});
Bir akıştaki ilk başarısızlığı kurtarmak için normalde yukarıdaki kod parçacığında gösterilen modeli kullanırdım. Yukarıdakini takip edecek istek, mevcut yanıttan alınan verilere dayanır ve bu nedenle ortama kaydedilir. İşlevin başlangıcında, bir sonraki istek boş olarak ayarlanır, bu, bir sonraki isteğin olmamasını sağlar. Bununla birlikte, işlev herhangi bir onaylama hatası veya istisna olmaksızın son ifadesine ulaşırsa, sonraki istek, koleksiyon içinde sırayla sonraki istek olarak ayarlanır; böylelikle ilk başarısızlığı kurtarmamıza, ancak işler gerektiği gibi gittiğinde devam etmemize olanak tanıyor.
Waiting in Loops
Bazı API'lerimizde, bir istek gönderildiğinde, bir kullanıcı uygulamasının isteğinin ilerleyişini takip edebilmesi için bir takip numarası veya bağlantı döndürülür. Bu davranışı Postman kullanarak test etmek, ilk isteği başlatmayı, izleme bilgilerini kaydetmeyi ve ardından bu bilgileri isteği tamamlanana kadar her aralıkta izlemek için kullanmayı gerektirir.
pm.test(`${pm.info.requestName} - initiate request.`, function () {
postman.setNextRequest(null);
pm.expect(pm.response).to.have.property('code', 201);
const body = pm.response.json();
pm.expect(body.status).to.eql('PENDING');
pm.environment.set('statusCheckLink', body.tracking.href);
pm.environment.set('statusCheckCounter', 0);
postman.setNextRequest();
});
Yukarıdaki kod parçacığında, izleme bağlantısını yanıt gövdesinden çıkarıp ortama kaydediyorum. Ayrıca, halihazırda gerçekleştirilen durum kontrollerinin sayısını takip etmek için bir sonraki istek tarafından kullanılacak bir sayacı başlatıyorum.
const statusCheckCounter = pm.environment.get('statusCheckCounter');
pm.test(`${pm.info.requestName} - procedure status check #${String(statusCheckCounter).padStart(2,0)}`, function() {
postman.setNextRequest(null);
pm.expect(pm.response).to.have.property('code', 200);
const body = pm.response.json();
pm.expect(body.status).to.not.eql('FAILED');
if (body.status === 'COMPLETED') {
// Completion checks...
pm.environment.unset("statusCheckCounter");
postman.setNextRequest();
} else {
pm.expect(statusCheckCounter).to.be.below(60, 'The procedure did not finish within a reasonable time.')
pm.environment.set('statusCheckCounter', statusCheckCounter + 1);
postman.setNextRequest(`${pm.info.requestName}`);
setTimeout(function(){}, 10000);
}
});
Bu kodda, durum kontrol bağlantısını arayarak alınan yanıtı kontrol ediyorum. Sonucun durumu nihai değilse, durum kontrol sayacını artırıyorum, sonraki isteği mevcut istek olarak ayarlıyorum ve 10 saniye bekliyorum. Bu mantık, durum nihai, tamamlanana, başarısız oluncaya veya durum kontrol sayacı eşiğine ulaşıncaya kadar kendini tekrarlayacaktır.
Data-Driven Testing - Veriye Dayalı Test
Postman'ı regresyon testi çözümüne kabul etmek için, JMeter testlerimizde kullandığımız herhangi bir özellik ve yeteneğin Postman'da bir eşdeğeri veya alternatifi olduğundan emin olmak gerekiyordu. Bunlardan biri veriye dayalı testtir. JMeter'da, ya bir CSV veri kümesi yapılandırma öğesi kullanırız ya da gerçekten harika komut dosyası içindeki dosyayı (genellikle bir JSON) okurduk.
Postman, kullanıcının bir CSV veya JSON belirtmesine izin verir ve toplama çalıştırıcısı tarafından veya bir CLI seçeneği aracılığıyla Newman tarafından bir veri dosyası olarak kullanılır. CSV'den daha fazla veri türü çeşitliliğine izin verdiği ve komut dosyaları JS dilinde yazıldığı için daha uygun olduğu için bir veri dosyası hazırlarken özel olarak JSON formatını kullanmayı seçiyorum.
[
{
"caseName": "Case #1",
"resourceId": "2040025_0001_0001_01",
"response_self": {...},
"response_parent": {...},
"response_children": [{...}, {...}]
},
{
"caseName": "Case #2",
"resourceId": "2030014_0002_0001_01",
"response_self": {...},
"response_parent": {...},
"response_children": [{...}, {...}, {...}]
}
]
JSON veri dosyası için gerekli format - yukarıda gösterildiği gibi - bir dizi nesnedir. Postacı çalıştırıcısı, dizi üzerinde yineleme yapacak ve dizideki her nesne için koleksiyonu yürütecektir.
const caseName = pm.iterationData.get('caseName');
const resourceId = pm.iterationData.get('resourceId');
const expectedResponses = pm.iterationData.toObject();
pm.environment.set('caseName', caseName);
pm.environment.set('resourceId', resourceId);
pm.environment.set('expectedResponses', exepectedResponses);
Yineleme verilerine get (…) ve toObject () gibi işlevler aracılığıyla pm.iterationData aracılığıyla erişilebilir . Genellikle yineleme verilerini çıkarır ve koleksiyondaki ilk isteğin ön istek komut dosyası sırasında hemen ortama kaydederdim.
Code Reuse - Kodun Yeniden Kullanımı
Tüm gereksinimlerin yanıtlandığından ve Postman'ın regresyon testi çözümümüze entegre edilebileceğinden emin olduktan sonra, tüm paydaşlarla yeni teknolojiyi kabul etme süreci, faydaları ve onu kullanma yolları hakkında konuşmak için bir toplantı ayarladım. Toplantı sırasında yapılan önemli bir yorum, kodun yeniden kullanımına ilişkindi. Gösterdiğim kod örneklerinde, çıkarmaya ve doğrulamaya zahmet etmediğim bir model vardı ve açıkçası konuya çok fazla vurgu yapmadım. Sanırım her koleksiyon diğerlerinden bağımsız olduğu için koleksiyonların ortak bir kütüphaneye sahip olması için hiçbir neden yok diye düşünüyordum.
Toplantı biter bitmez öfkeyle google'a başladım! Postman'a harici kütüphanelerin aktarılmasından bahseden okuduğum her gönderi aynı cevabı verdi - ilk başta beğenmedim ama kabul ettim. Görünüşe göre, harici bir kitaplığı içe aktarmanın tek yolu, bir CDN bağlantısında yapacağınız gibi, onu bir istek yoluyla almaktı.
pm.sendRequest('http://{{GITLAB_IP}}/snippets/3/raw', (error, response) => {
if (error) {
throw error;
} else {
pm.environment.set('utilsRaw', response.text());
}
});
Bu yüzden, sonuçta yaptığım şey, yukarıdaki kodu, yardımcı program kodumuzu kullanmak istediğim herhangi bir koleksiyonun ilk talebinin ön istek komut dosyasına yerleştirmekti. Bu yardımcı program kodu, organizasyon ağında halka açık olarak erişilebilen herhangi bir yerde saklanabilir. Bu örnekte, iş için Gitlab parçacıklarını listeledim.
eval(pm.environment.get('utilsRaw'));
Karşılaştığım kullanım durumunda, pm nesnesine ek işlevler eklemeye karar verdim . Bunu yapmak için bu eval ifadesini, bu ek işlevleri kullanmak istediğim herhangi bir komut dosyasının başında çalıştırıyorum.
Bahsetmediğim, hatta araştırmadığımı bildiğim daha birçok özellik var; takım çalışma alanları, çatallanma ve sahte sunucular gibi. Bu, bu özelliklere bakma ihtiyacım olmamasının basit nedeninden kaynaklanıyor. Bununla birlikte, gözden geçirilmiş test çözümü üzerinde ne kadar çok çalışırsam, o kadar derine inmem ve bu hikayeyi geri getirip güncellememi sağlayacak bazı yeni şeyler keşfetmem gerekebileceğini görüyorum. O zamana kadar, yazdığım ipuçlarını ve püf noktalarını faydalı bulduğunuzu umuyorum.