<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*kQRegJyS05tl1aQ6fGAVAw.jpeg"><figcaption>json parse immutable</figcaption></figure><blockquote>
JavaScript ES6+ serisindeki bir önceki yazı: <a href="https://tugsanunlu.medium.com/javascript-es6-i%CC%87pu%C3%A7lar%C4%B1-8-object-groupby-ile-dizileri-gruplamak-80faf6645fd4">JavaScript ES6+ İpuçları #8: Object.groupBy() ile Dizileri Gruplamak</a>
</blockquote>
Pandemi döneminde yazdığım JavaScript ES6+ İpuçları serisindeki yazılardan birisi de <a href="https://tugsanunlu.medium.com/javascriptde-record-tuple-ile-native-de%C4%9Fi%C5%9Fmezlik-sa%C4%9Flamak-7364b275bc82">Record ve Tuple ile Native Değişmezlik Sağlamak</a> başlıklı, önceleri <a href="https://immutable-js.com/">Immutable.js</a> gibi üçüncü parti kütüphanelerle sağladığımız değişmezlik özelliğinin, JavaScript’e kazandırılması üzerineydi. Maalesef o yazının üstünden geçen dört senelik zamanda bu özellik standart olamadı. Hâlâ <a href="https://tc39.es/process-document/">TC39 sürecinde</a> ikinci aşamada <a href="https://github.com/tc39/proposal-record-tuple">yer alıyor</a>.
<h4>JSON.parseImmutable()</h4>
Çoğunluğunu, Record ve Tuple önerisinin geliştiricilerinin oluşturduğu bir grup geliştirici, Record ve Tuple önerisi içerisinde yer alan ve JSON formatındaki veriler için derinlemesine değişmezlik sağlayan parseImmutable() metodunu, JSON objesine dahil edecek ayrı bir öneri <a href="https://github.com/tc39/proposal-json-parseimmutable?tab=readme-ov-file">sundu</a> TC39'a.
Aslında <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze">Object.freeze() metodu</a> bize benzer bir değişmezliği sağlıyordu. Fakat bunu yalnızca objeler içerisindeki ilkel tipteki veriler (primitive) için yaptığından içe içe (nested) veri yapılarında ve referans tipteki veriler için tam olarak ihtiyacı karşılamıyordu. JSON.parseImmutable() bunu tüm veri tipleri için, derinlemesine (deep immutability) yapmayı amaçlıyor.
Kullanımı ise oldukça basit.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*tfL_T2HoDrCcrpfZmbiquQ.png"></figure><h4>Sonuç</h4>
JSON.parseImmutable() metodu da tıpkı Record ve Tuple gibi, Ağustos 2024 itibarıyla TC39 sürecinde ikinci aşamada yer alıyor. Fakat bağımlılığı Record ve Tuple’a göre çok daha az olduğu için sonraki aşamalara daha kısa sürede geçeceği düşünülüyor topluluk tarafından. Yine bu özelliği projelerimizde veya deneysel çalışmalarımızda kullanabilmek için <a href="https://babeljs.io/docs/babel-preset-stage-2">TC39 ikinci aşama önerilerini</a> Babel yapılandırmalarımıza eklememiz gerekiyor.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://tc39.es/proposal-json-parseimmutable/">https://tc39.es/proposal-json-parseimmutable</a></li>
<li><a href="https://github.com/tc39/proposal-json-parseimmutable">https://github.com/tc39/proposal-json-parseimmutable</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ca148b32ec02" width="1" height="1" alt="">

JavaScript ES6+ İpuçları #9: JSON.parseImmutable ile Değişmezlik Sağlamak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*GcTF_n65C3QtcrpprF3LIQ.jpeg"><figcaption>axios progress capturing</figcaption></figure><blockquote>Axios serisindeki bir önceki yazı: <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-5-axios-mock-adapter-ile-http-i%CC%87steklerini-mocklamak-4b2c586f4ae1">Axios İpuçları #5: Axios Mock Adapter ile HTTP İsteklerini Mocklamak</a>
</blockquote>
Pandemi döneminde yazmaya başladığım ipucu serilerinden birisi de <a href="https://github.com/axios/axios">Axios</a> için olandı. HTTP isteklerini iptal etmek için <a href="https://tugsanunlu.medium.com/axios-cancel-token-ile-http-i%CC%87steklerini-i%CC%87ptal-etmek-b60fe8f725d4">cancel token kullanımı</a>, interceptor kullanarak <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-2-interceptor-kullanarak-http-i%CC%87stek-ve-yan%C4%B1tlar%C4%B1n%C4%B1-y%C3%B6netmek-76cffa9139d2">HTTP istek ve yanıtlarını yönetmek</a>, <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-3-lru-cache-ile-http-yan%C4%B1tlar%C4%B1n%C4%B1-%C3%B6nbelleklemek-4ecbf40434d0">LRU yöntemiyle önbellekleme</a>, <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-4-localforage-ile-http-yan%C4%B1tlar%C4%B1n%C4%B1-indexeddbde-%C3%B6nbelleklemek-c246ebf6d8f8">IndexedDB’de önbellekleme</a>, <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-5-axios-mock-adapter-ile-http-i%CC%87steklerini-mocklamak-4b2c586f4ae1">HTTP isteklerini mocklamak</a> gibi farklı konularda yazılar yazmıştım. Hem Axios’un yeni sürümleriyle birlikte gelen hem de daha önce bahsetmediğim özelliklerle birlikte bu seriye devam etmek niyetindeyim.
<h4>Motivasyon</h4>
HTTP isteklerini yaparken veya yaptığımız HTTP isteklerinin yanıtlarını beklerken kullanıcılarla farklı yöntemler sayesinde etkileşime geçiyoruz. Bu yöntemler, bazen kullanıcının gördüğü ekranın tamamını veya bir kısmını geçici olarak atıl duruma getirmek olurken bazen de yalnızca istek — yanıt döngüsünün başladığı bilgisinin kullanıcıya verilip uygulamanın geri kalanını kullanmaya devam etmesinin sağlanması olabiliyor.
Kullanıcıların her daim en güncel ve doğru verileri görmesi, ilki tamamlanmadan aynı sürecin ikiniciye tetiklenmesinin önüne geçilmesi gibi endişeler konu olduğunda bu yöntemler gayet iş görüyor. Fakat bekleme süreleri arttıkça kullanıcılar bir bilinmezi beklemeye başlıyorlar. Bu da kötü bir kullanıcı deneyiminin yanı sıra; işlemin, bir hata olduğu şüphesiyle kullanıcı tarafından iptal edilmesi gibi tehlikeleri beraberinde getiriyor.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/480/0*Zwqn2b9BwSWcH-ND.gif"></figure>Bunun önüne geçmek için kabaca iki seçeneğimiz var. İlki, kullanıcıya işlemin tamamlanacağı tahmini süreye göre sahte bir ilerleme durumu göstermek. %99'a birkaç saniyede gelip %100 olması dakikaları bulan ilerleme durumları genelde bu yöntemle yapılıyor. Bir diğeri ise ilerleme durumunu doğrudan kaynağından, bizim senaryomuzda Axios'un bize sağladığı onUploadProgress ve onDownloadProgress callback fonksiyonlarından almak.
<h4>onUploadProgress, onDownloadProgress</h4>
Örnek olarak Axios’da bir POST isteğinin nasıl yapıldığını hatırlarsak, axios.post metodu üç adet argüman alıyordu. Bunlardan ilki POST isteğinin yapılacağı URL, ikincisi POST isteğiyle gönderilecek veri, üçüncüsü de header vb. diğer opsiyonel verilerin yer aldığı options nesnesi. onUploadProgress ve onDownloadProgress callback fonksiyonlarını bize bu options nesnesi sağlıyor. Bu fonksiyonlar, içerisinde upload ve download bilgilerinin yer aldığı birer event nesnesi dönüyorlar.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*VhLVnYHinsw2kIfpRIFTzQ.png"></figure>Bu nesnelerdeki belli başlı ortak alanların ne olduğuna ve hangi verileri döndüklerine bir bakalım.
loaded: Yüklenen/indirilen veri boyutu total: Toplam veri boyutu progress: İlerleme durumu (0 ila 1 arasında) bytes: Son tetiklemeden bu yana yüklenen byte sayısı estimated: Tahmini kalan süre (saniye olarak) rate: Yükleme hızı (byte olarak)
<h4>Sonuç</h4>
Bu verileri dinleyerek uygulama içerisindeki ilerleme durumlarını dinamik olarak yönetmek mümkün hale geliyor. Yüklenen veya indirilen veri boyutunu, toplam veri boyutuna oranlayarak yüzdelik dilimler oluşturulabileceği gibi tahmini kalan süre ve yükleme hızı bilgileriyle daha detaylı görsel sayaçlar oluşturulabilir.
Fakat bu verilerin, cihazların internet bağlantılarındaki anomali durumlarından etkilenip tutarsız davranabileceğini de unutmamak gerekiyor. O yüzden bu verileri veya bu verilerle oluşturulan ilerleme durumlarını doğrudan son kullanıcılara göstermek pek güvenli olmayacaktır. Onun yerine bu bilgileri gerekli manipülasyonlardan geçirdikten sonra (minimum ve maksimum değerlerin belirlenmesi, bir önceki değerle mukayese vs. gibi) yukarıda bahsettiğim sahte ilerleme durumlarına veri kaynağı olarak beslemek ve her iki yöntemi birlikte kullanmak daha iyi bir kullanıcı deneyimi oluşturulmasına katkı sağlayacaktır.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://github.com/axios/axios?tab=readme-ov-file#-progress-capturing">https://github.com/axios/axios?tab=readme-ov-file#-progress-capturing</a></li>
<li><a href="https://axios-http.com/docs/req_config">https://axios-http.com/docs/req_config</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=395aaaa8d135" width="1" height="1" alt="">

Axios İpuçları #6: HTTP İsteklerinde Upload/Download Bilgilerini Yakalamak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*uHbeY-xipQZmE8t0yEwKag.jpeg"><figcaption>array grouping</figcaption></figure><blockquote>JavaScript ES6+ serisindeki bir önceki yazı: <a href="https://medium.com/@tugsanunlu/javascript-es6-i%CC%87pu%C3%A7lar%C4%B1-7-at-metoduyla-i%CC%87stenilen-i%CC%87ndeksteki-de%C4%9Fere-eri%C5%9Fmek-7b6b2c0fa32">JavaScript ES6+ İpuçları #7: at() Metoduyla İstenilen İndeksteki Değere Erişmek</a>
</blockquote>
Pandemi dönemi ve sonrasında <a href="https://tugsanunlu.medium.com/javascript-es6-i%CC%87pu%C3%A7lar%C4%B1-7-at-metoduyla-i%CC%87stenilen-i%CC%87ndeksteki-de%C4%9Fere-eri%C5%9Fmek-7b6b2c0fa32">JavaScript ES6+</a>, <a href="https://tugsanunlu.medium.com/webpack-i%CC%87pu%C3%A7lar%C4%B1-4-content-hash-ile-bundle-dosyalar%C4%B1n%C4%B1n-taray%C4%B1c%C4%B1-%C3%B6nbelle%C4%9Finde-kalmas%C4%B1n%C4%B1-%C3%B6nlemek-441047328799">Webpack</a>, <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-5-chrome-devtools-recorder-ile-test-senaryolar%C4%B1-olu%C5%9Fturmak-fb6add3e8238">Cypress</a>, <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-5-axios-mock-adapter-ile-http-i%CC%87steklerini-mocklamak-4b2c586f4ae1">Axios</a> gibi farklı konularda seri yazılar yazmıştım. Diğerleri gündelik hayat pratiklerine ve deneyimlere dayanırken JavaScript ES6+ yazıları, JavaScript’e seneler sonra gelecek özelliklere bugünden bakmayı sağlıyordu. O yüzden yazmadan önceki hazırlıkları ve uyumluluk kontrolleriyle en çok keyif aldığım yazılardı.
Geçtiğimiz günlerde <a href="https://github.com/tc39/proposals?tab=readme-ov-file">TC39 proposal’larına</a> bakarken bu seriye son yazıyı neredeyse üç sene önce yazdığımı fark ettim ve dayanamayıp yeni özelliklerden birinden kısaca bahsetmek istedim.
<h4>Object.groupBy()</h4>
<a href="https://tc39.es/process-document/">TC39 proposal akışında</a> Stage 4'de, yani standartlaşmaya hazır olan bu özelliğin ismi array grouping. Bir diğer ismiylegroupBy. <a href="https://en.wikipedia.org/wiki/SQL">SQL</a> ile yolu kesişmiş olanların aşina oldukları bir özellik. Yaptığı iş de isminden anlaşılacağı üzere oldukça basit, eldeki veriyi, verinin içerisindeki bir değere veya kritere göre gruplamak.
Elimizde aşağıdaki gibi bir cihaz listesi olduğunu ve bu listedeki cihazları, kullandıkları çipsetlere göre gruplamak istediğimizi varsayalım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*t7AVewi5Rw3dthCx7PLS5g.png"></figure>JavaScript’de groupBy özelliğinin olmadığı dünyada bunu yapmak istediğimizde, işimizi görecek fakat karmaşık ve okuması güç <a href="https://stackoverflow.com/questions/14446511/most-efficient-method-to-groupby-on-an-array-of-objects">fonksiyonlar yazabiliyor</a> veya <a href="https://lodash.com/">Lodash</a> gibi utility kütüphanelerindeki <a href="https://lodash.com/docs/4.17.15#groupBy">dizi fonksiyonlarından</a> faydalanabiliyorduk.
Object.groupBy(), verilen değeri key, bu değere göre gruplanan verilerin oluşturduğu dizileri de value olarak kullanıldığı bir obje dönerek bu işi pratik şekilde hallediyor. Eğer key olarak değer değil de index kullanmak istenirse de Map.groupBy() aynı işi yapıyor.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*iiE7E08CxsMmDlXURUP_Tg.png"></figure>Majör web tarayıcılarının JavaScript motorlarına, 2023'ün son çeyreğindeki güncellemelerle birlikte (Chrome için 117 ve üstü, Safari için 17.4 ve üstü) dahil olan özelliğe, daha eski tarayıcılarda da sahip olmak için her zamanki gibi yine <a href="https://github.com/zloirock/core-js#array-grouping">polyfill kullanmak</a> gerekiyor.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://github.com/tc39/proposal-array-grouping">https://github.com/tc39/proposal-array-grouping</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/groupBy">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/groupBy</a></li>
</ul>
<blockquote>JavaScript ES6+ serisindeki bir sonraki yazı: <a href="https://tugsanunlu.medium.com/javascript-es6-i%CC%87pu%C3%A7lar%C4%B1-9-json-parseimmutable-ile-de%C4%9Fi%C5%9Fmezlik-sa%C4%9Flamak-ca148b32ec02">JavaScript ES6+ İpuçları #9: JSON.parseImmutable ile Değişmezlik Sağlamak</a>
</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=80faf6645fd4" width="1" height="1" alt="">

JavaScript ES6+ İpuçları #8: Object.groupBy() ile Dizileri Gruplamak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*2vfd6p8UvRJKyGL6kNaQ4Q.png"></figure><h4>Nedir?</h4>
Geliştirdiğimiz uygulamaların veya uygulama parçalarının, beklediğimiz şekilde çalıştığından emin olmak ve bunun sürekliliğini sağlamak için ihtiyaca yönelik olarak birim testler, entegrasyon testleri veya uçtan uca testler yazıyoruz. Bu testler çoğu zaman bir fonksiyonun veya akışın, aynı girdilerle çalıştırıldığında aynı çıktıları vermesini, yani deterministik olmasını amaçlıyorlar. Fakat kimi zaman da girdilerle çok fazla uğraşmadan, elimizdeki çıktıları, daha önce aldığımız çıktılarla karşılaştırmak ve buradan bir sonuca varmak da pratik bir çözüm olabiliyor. Bu saikle yapılan testlere snapshot test ismi veriliyor.
<h4>Örnek</h4>
Bir web uygulamasının sayfa başlıklarında kullandığımız çok basit bir React component’i olduğunu düşünelim elimizde. Bu component birkaç stile sahip olsun ve dışarıdan bir başlık metni alsın.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TCg0e2jUwiK-4U970wu93Q.png"><figcaption>title.jsx</figcaption></figure>Bu component içerisinde yazılan JSX kodu, render olduğunda aşağıdaki gibi bir HTML çıktı elde edeceğiz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QSKlSYDfhg_5KjvYyJShMw.png"><figcaption>title.jsx render</figcaption></figure>Component içerisinde, component’in çıktısını değiştirebilecek bir kondisyon olmadığını bildiğimiz için, bu component’in aynı girdilerle her render edildiğinde aynı HTML çıktıyı vereceğinden eminiz. Bu sayede her defasında component’e dışarıdan doğru şekilde prop geçebiliyor muyuz, geçtiğimiz prop, istediğimiz şekilde son kullanıcıya gösteriliyor mu gibi testleri daha pratik bir şekilde yapabiliyoruz.
JavaScript ekosisteminde kullandığımız test runner aracı <a href="https://jestjs.io/">Jest</a>, snapshot testler için oldukça basit bir API <a href="https://jestjs.io/docs/snapshot-testing">sunuyor</a>. Jest, aşağıdaki test dosyası çalıştırıldığında Title component’i için daha önce alınmış bir snapshot dosyası varsa eğer component’in güncel çıktısı ile o dosyayı karşılaştırıyor. Eğer yoksa sonraki testlerde kullanılmak üzere .snap uzantılı yeni bir snapshot dosyası oluşturuyor.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QzZzAArpPLjV67SY7OyBUw.png"><figcaption>title.test.js</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*pppiJGdo2sV25DkdupS_Iw.png"><figcaption>title.test.js.snap</figcaption></figure>Oluşturulan snapshot dosyaları, test senaryolarında ortaya attığımız <a href="https://jestjs.io/docs/expect">assertion</a>’lar (iddialar) yerine geçiyor ve zaman kısıtı olan projelerde bizi her durum için yeni bir assertion yazma ihtiyacından kurtarıyor. Yine oluşturulan bu snapshot dosyalarını versiyon kontrol sistemleriyle birlikte repolarımıza dahil ettiğimizde ise CI (Continous Integration) süreçlerinde de snapshot testlerimizi koşturabiliyoruz.
<h4>Ne Değildir?</h4>
Snapshot testinin ne olmadığına değinmek gerekirse; snapshot testi bir <a href="https://en.wikipedia.org/wiki/Test-driven_development">TDD</a> (Test Driven Development / Test Güdümlü Geliştirme) yöntemi değil. Bilindiği üzere TDD pratiklerinde bir kodun ilk olarak testi yazılır ve başarısız olur. Sonrasında yazılan test başarılı olana kadar ilgili kod parçacığı adım adım yazılır. Fakat snapshot testi yazarken doğru çalıştığından emin olduğumuz bir kod parçacığının elimizde olması gerekir. Bu nedenle çalıştırılan ilk snapshot testleri her zaman başarılı olur.
Bir diğer konu, snapshot testleri görsel bir karşılaştırma yapmadığı için çıktılarında oluşabilecek farklılıkları gözle anlamlandırmak gerekebilir. Yukarıdaki aynı component’i ele alalım örneğin. Aşağıdaki her iki kullanım da son kullanıcıya aynı görsel arayüzü verir. Fakat geliştirme esnasındaki tercihlerden dolayı render edilen çıktılarda farklılıklar oluşacaktır. Jest, snapshot testlerinin çalışma prensibi gereği bunun bir hata olduğuna dair alarm verecek ama son kullanıcıya etkisi açısından <a href="https://en.wikipedia.org/wiki/False_positives_and_false_negatives">false positive</a> bir durum oluşturacaktır. Bu durumda ya ilgili kod parçacığının değiştirilmesi ya da sorumluluğun kabul edilerek snapshot dosyasının yeni çıktıyla güncellenmesi gerekecektir.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*5Z836CEkxzDVJehOw2ixlQ.png"><figcaption>title-1.jsx</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QBaDkfdmYz7rNyLMVDPlgA.png"><figcaption>title-2.jsx</figcaption></figure>Tüm bunlarla birlikte, Jest geliştiricilerinin de <a href="https://jestjs.io/docs/snapshot-testing#does-snapshot-testing-replace-unit-testing">üzerinde durduğu gibi</a> snapshot testlerinin, geleneksel birim testlerinin yerini almak gibi iddiası veya misyonu yok. Bilakis, birim testleri destekleyen, tamamlayıcı bir yöntem olarak uygulanıyorlar.
<h4>Sonuç</h4>
Snapshot testler, özellikle atomik component’lerin testi için oldukça düşük maliyetli ve kullanışlı bir test yöntemi. Fakat component’ler, varoluşlarının aksine birden fazla işi yapmaya başlayarak büyüdüğünde, snapshot testlerinin yönetimi de doğru orantılı olarak güçleşiyor. Snapshot testleri, zaman kısıtı olan projelerde eforsuz bir kurtarıcı olarak, onun dışında kalan diğer tüm projelerde ise mevcut testlerin bir destekçisi olarak kullanmak en doğru pratik olacaktır.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://jestjs.io/docs/snapshot-testing">https://jestjs.io/docs/snapshot-testing</a></li>
<li><a href="https://kentcdodds.com/blog/effective-snapshot-testing">https://kentcdodds.com/blog/effective-snapshot-testing</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d5bd5418c14f" width="1" height="1" alt=""><hr>
<a href="https://medium.com/akbank-teknoloji/snapshot-testi-nedir-ne-de%C4%9Fildir-d5bd5418c14f">Snapshot Testi Nedir, Ne Değildir?</a> was originally published in <a href="https://medium.com/akbank-teknoloji">Akbank Teknoloji</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Snapshot Testi Nedir, Ne Değildir?

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*kFvF56jG_pvhd_0RzOhw2g.jpeg"></figure><h4>Motivasyon</h4>
Platform veya teknoloji fark etmeksizin, geliştirdiğimiz projelerde üçüncü parti paketlere sıklıkla başvuruyoruz. Bunu yaparken, kod tekrarını önlemek, geliştirilen birden fazla proje için benzer/aynı araçları kullanmak, genel ihtiyaçlar için özel çözümler üretmek yerine, uzun süredir canlı ortamlarda sorunsuz şekilde çalışan, topluluk desteği olan muadil çözümleri tercih etmek gibi farklı amaçlarımız olabiliyor.
Projemize dâhil ettiğimiz bu bağımlılıkları ve beraberindeki alt bağımlılıklarını düzenli olarak veya bir uyaran sonrasında güncellemediğimiz takdirde, o bağımlılıklardan doğacak tüm riskleri peşinen kabul etmiş oluyoruz. İdeali, düzenli olarak yapacağımız yükseltmelerle bağımlılıklarımızı güncel tutmak olsa da maalesef gerçek hayat şartlarında bu her zaman mümkün olmayabiliyor. Kullandığımız üçüncü parti paketlerin birbirleriyle uyumu, majör sürüm değişiklikleri sonrasındaki gerekecek kod değişiklikleri, değişiklikler sonrasında oluşacak regresyon test maliyetleri sebebiyle sürüm yükseltmeleri bilinmez bir ileri tarihe ötelenebiliyor.
Bu durumda, kullandığımız paketleri belli kriterlere uymadıkları koşullarda güncellemek alternatif bir yöntem olarak karşımıza çıkıyor.
<h4>Zafiyetli Paketin Yaşam Döngüsü</h4>
Bir gerçek hayat örneği üzerinden açıklarsak, geliştirmek istediğimiz yönetim paneli projesinde React ile sıfırdan bir mimari kurgulamak istemedik ve <a href="https://github.com/marmelab/react-admin">react-admin</a> framework’ünü kullanmaya karar verdik diyelim. Bu kararı aldığımızda react-admin’in en güncel sürümü olan 4.0.0'ı projemize dahil ettik ve kullanmaya başladık.
Aradan aylar geçti, react-admin’i geliştiren topluluk, framework’deki güvenlik zafiyetlerini bir bir bulup kapatmaya başladı. Bunlardan bir tanesi de RichTextField isimli arayüz component’inde XSS (Cross-Site Scripting)’e neden olan <a href="https://github.com/marmelab/react-admin/security/advisories/GHSA-5jcr-82fh-339v">zafiyetti</a>. Topluluk zafiyeti fark edince hızlıca harekete geçip 4.7.6 sürümünde zafiyeti kapattı. Fakat bizim bu zafiyetin varlığından dahi haberimiz yok henüz. Halbuki tüm bu süreç şeffaf bir şekilde yaşandı. Peki ne oldu?
Zafiyeti fark eden <a href="https://github.com/fzaninotto">Francois Zaninotto</a> isimli geliştirici, GitHub’daki projede zafiyeti kapatacak geliştirmeyi yapıp bir <a href="https://github.com/marmelab/react-admin/pull/8644">PR (pull request) açtı</a>. Bu PR’da zafiyetin ne olduğunu, nasıl çözdüğünü ve zafiyetsiz halinin paketin hangi sürümüyle birlikte yayımlanacağını belirtti. Kodu diğer arkadaşları tarafından incelendi ve kabul edildi.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*ivrAbEgxNZemvzWxIpb2GA.png"><figcaption><a href="https://github.com/marmelab/react-admin/pull/8644">https://github.com/marmelab/react-admin/pull/8644</a></figcaption></figure>Akabinde, Francois Zaninotto topluluğa duyurmak üzere yine projenin GitHub sayfasında bir güvenlik duyurusu <a href="https://github.com/marmelab/react-admin/security/advisories/GHSA-5jcr-82fh-339v">yayımladı</a>. Burada PR’dakilerin yanı sıra zafiyetten hangi sürüm aralıklarının etkilendiği ve öncelik seviyeleri gibi detay bilgileri de paylaştı. GitHub bu aşamada zafiyete özel, eşsiz bir ID ataması (Üstteki zafiyet için GHSA-5jcr-82fh-339v) yapıyor. Bu ID ile de zafiyetin durumu <a href="https://github.com/advisories/GHSA-5jcr-82fh-339v">takip edilebiliyor</a>.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*8WrydEXZTEV1ZBWOoatqpw.png"><figcaption><a href="https://github.com/marmelab/react-admin/security/advisories/GHSA-5jcr-82fh-339v">https://github.com/marmelab/react-admin/security/advisories/GHSA-5jcr-82fh-339v</a></figcaption></figure>Tabii projemizde kullandığımız yüzlerce bağımlılık için bu duyuruları tek tek takip edip harekete geçmemiz mümkün değil. Onun yerine paket yöneticilerinin sağladığı audit araçlarıyla projemizin belli koşullardan alarm oluşturmasını sağlayabiliriz.
<h4>audit-ci</h4>
audit-ci, ufak ve pratik bir CLI (Command Line Interface) aracı. JavaScript ekosistemindeki projelerde kullandığımız üçüncü parti paketlerdeki bilinen güvenlik zafiyetlerini taramamızı sağlıyor.
Aslında her paket yöneticisinin npm-audit, yarn audit gibi bir zafiyet denetim aracı bulunuyor. Fakat audit-ci, hem farklı paket yöneticileriyle çalışabilmesi hem de sağladığı diğer kullanışlı özelliklerden dolayı tercih ediliyor.
Kullanmaya başlamak için audit-ci’ı bir geliştirme ortamı bağımlılığı olarak kuruyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*4XLrV-UHKb4-ZKRLc8u5Lg.png"><figcaption>Kurulum</figcaption></figure>Akabinde hiçbir yapılandırmaya ihtiyaç duymadan, yalnızca bağımlılıklarımızdaki hangi seviyedeki zafiyetleri yakalamak istediğimizi belirtiyoruz. Önem derecesine göre sırasıyla low, moderate, high ve critical değerlerini kullanabiliyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*MRIyt7GL95g2NxfT96mSUQ.png"><figcaption>CLI argümanlarıyla çalıştırma</figcaption></figure>Bunun sonrasında audit-ci, projemizdeki tüm bağımlılıkları tarayacak ve moderate ve üstü seviyede bir zafiyet tespit ettiği takdirde bizi aşağıdaki gibi bir çıktıyla uyaracak.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*hrKxKQ0eKEMpisghwT2yuw.png"><figcaption>Sonuç çıktısı</figcaption></figure><h4>Yapılandırma Dosyası Oluşturmak</h4>
Üstteki gibi CLI argümanlarını kullanmak yerine bir yapılandırma dosyası oluşturup audit-ci’ın ona bakmasını da sağlayabiliriz. Bunun için .jsonc uzantılı bir dosya oluşturuyoruz. .jsonc, bildiğimiz JSON veri formatının içerisine yorum satırları da yazılabilen bir versiyonu.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*keiVyAfgZqj9iwya1l5xXQ.png"><figcaption>audit-ci.jsonc</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*dHmOoHc5752eWhavoJJEGQ.png"><figcaption>Yapılandırma dosyasıyla çalıştırma</figcaption></figure>Sonrasındaki tüm taramalarımızı — config argümanına oluşturduğumuz yapılandırma dosyasının yolunu vererek yapabiliriz.
<h4>İstisna Tanımlamak</h4>
audit-ci’ın en kullanışlı özelliklerinden birisi de bir paketin tamamına veya paket içerisindeki bir zafiyete süreli veya süresiz olarak istisna tanımlayabilmek. Özellikle <a href="https://en.wikipedia.org/wiki/Continuous_integration">CI (Continuous Integration)</a> entegrasyonlarında ihtiyaç duyulan bu özellik sayesinde sorumluluğunu kabul ederek iş akışlarınızın kesilmemesini sağlayabiliyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*C4yJuGKAVHYDJ7r80t-QcA.png"><figcaption>Zafiyet istisnası</figcaption></figure>Bunun için doğrudan zafiyetin eşsiz ID’sini kullanabiliyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/943/1*6GRncMTwVwD9ne6Y0RjAsg.png"><figcaption>Belli tarihli paket istisnası</figcaption></figure>Ayrıca paketin tamamının belirli bir tarihe kadar audit-ci tarafından göz ardı edilmesini de sağlayabiliyoruz.
<h4>output-format</h4>
audit-ci, varsayılan olarak metin bazlı bir çıktı veriyor. Fakat çıktının gözle okunması yerine farklı araçlarca işlenmesine ihtiyaç duyulduğunda JSON çıktısını da kullanabiliyoruz.
<h4>retry-count</h4>
Zaman zaman kesintiler sebebiyle paket yöneticilerinden veya zafiyet taramalarından istenilen bilgilerin alınamadığı durumlarda iş akışlarımız durabiliyor. Bu gibi sorunlar yaşamamak için herhangi bir hata alınması durumunda retry-count ile işlemin kaç defa daha tekrar edileceğini belirleyebiliyoruz.
<h4>skip-dev</h4>
Yukarıdaki örneklerde uygulamamız içerisindeki tüm bağımlılıklarda zafiyet taraması yaptırdık. Fakat kimi durumlarda geliştirme ortamındaki bağımlılıkların es geçilip yalnızca canlı ortamdaki bağımlılıklarda zafiyet taraması yapılmasını skip-dev ile sağlayabiliyoruz.
<h4>Sonuç</h4>
audit-ci, projelerin özellikle <a href="https://en.wikipedia.org/wiki/Continuous_integration">CI (Continuous Integration)</a> süreçlerine ve Git hook’larıyla geliştirme ortamlarına dahil edildiğinde, insan kaynaklı ihmalleri olabildiğince ortadan kaldıran ve üçüncü parti paket kullanımında hakimiyet sağlayan bir CLI aracı. Kurulum ve yapılandırmasının pratikliğinden dolayı tak-çalıştır şeklinde geliştirmesi devam eden mevcut projelere eklenebilmesi, alarm kurallarının esnetilebilmesi, çıktıları sayesinde farklı güvenlik araçlarıyla iletişim kurabilmesi ise diğer iyi özelliklerinden bazıları.
Bir sonraki yazımızda görüşmek üzere…
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://www.npmjs.com/package/audit-ci">https://www.npmjs.com/package/audit-ci</a></li>
<li><a href="https://github.com/IBM/audit-ci">https://github.com/IBM/audit-ci</a></li>
<li><a href="https://github.com/advisories/GHSA-5jcr-82fh-339v">https://github.com/advisories/GHSA-5jcr-82fh-339v</a></li>
<li><a href="https://github.blog/changelog/2021-10-03-the-npm-advisory-database-is-now-part-of-the-github-advisory-database/">https://github.blog/changelog/2021-10-03-the-npm-advisory-database-is-now-part-of-the-github-advisory-database/</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=64abe65a085d" width="1" height="1" alt=""><hr>
<a href="https://medium.com/akbank-teknoloji/audit-ci-ile-javascript-ba%C4%9F%C4%B1ml%C4%B1l%C4%B1klar%C4%B1nda-zafiyet-taramas%C4%B1-yapmak-64abe65a085d">audit-ci ile JavaScript Bağımlılıklarında Zafiyet Taraması Yapmak</a> was originally published in <a href="https://medium.com/akbank-teknoloji">Akbank Teknoloji</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

audit-ci ile JavaScript Bağımlılıklarında Zafiyet Taraması Yapmak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*FwPWcvB57iYmExe7hPdvfQ.jpeg"></figure><h3>Motivasyon</h3>
Bir uygulamanın veya uygulama parçasının hangi özelliklerine test yazılacağı ve bu testler yazılırken nasıl bir yol izleneceği özellikle test yazmaya yeni başlayan yazılım ve QA (<a href="https://en.wikipedia.org/wiki/Quality_assurance">Quality Assurance</a>) geliştiricilerin zihnini en çok kurcalayan sorulardan biridir. Yazılan test ister bir birim isterse de uçtan uca bir test senaryosu olsun, AAA Pattern ile önceliklendirilmemiş ve metodoloji seçimi yapılmadan yazılmış testler, çoğu zaman kendi içerisinde doğru şekilde çalışsa dahi uygulamanın doğru şekilde çalışıp çalışmadığıyla ilgili kesin cevap veremezler. Peki, test aşaması için çok önemli olan bu AAA Pattern nedir? Gelin, birlikte göz atalım.
<h3>AAA (Arrange, Act, Assert) Pattern</h3>
Tüm yazılım problemlerinde olduğu gibi test aşamasında da bir design pattern’e başvurmak en doğru yoldur. Bilindiği üzere design pattern’ler, yaygın sorunların çözümleri hakkında bir başvuru kılavuzu olarak kullanılırlar. AAA pattern (3A veya Triple A olarak da adlandırılır) de test yazarken başvuracağımız bir design pattern’dir. Arrange, Act ve Assert kelimelerinin baş harflerinden oluşan bu pattern, bir test senaryosunu anatomik olarak üç ana parçaya ayırarak yönetmeyi önerir.
<h3>Arrange</h3>
Arrange yani “hazırlık” bölümü, test senaryosu içerisinde ihtiyaç duyulacak fonksiyon ve verilerin tanımlandığı bölümdür. Bir test dosyasını, uygulama parçalarından ayrıştırılmış bir ortam olarak düşünelim; Arrange bölümünü, test dosyasının dış dünyayla iletişim kurduğu, uygulamanın gerekli noktalarına eriştiği ve bu noktalarla birtakım veriler paylaştığı bölümü olarak görebiliriz.
<h3>Act</h3>
Act yani “eylem” bölümü, bir önceki arrange adımında hazırlığı yapılan test ortamıyla kullanıcıların etkileşime geçtiği bölümdür. Bu bölümde uygulamanın özellikleri göz önünde bulundurularak farklı farklı birçok son kullanıcı etkileşimi senaryosu test edilebilir. Kullanıcının bir butona tıklaması, bir input’a veri girişi yapması veya bir sayfadan çıkıp başka bir sayfaya giriş yapması act bölümünde ele alınarak test edilir.
<h3>Assert</h3>
Assert yani “iddia” bölümü ise arrange bölümünde hazırlığı yapılan, act bölümünde etkileşime geçilen uygulamanın, bu adımların sonucunda nasıl bir davranış göstereceğine dair iddialarımızın yer aldığı bölümdür. Bir test senaryosunun başarılı veya başarısız olduğuna, bu bölümdeki iddianın gerçekleşip gerçekleşmemesine göre karar verilir. Sonuç olarak, doğru şekilde yazılmış her test senaryosunun en az bir iddia içermesi gerekir.
<h3>Örnek Testler</h3>
Haydi şimdi, popüler test kütüphanelerinden React Testing Library kullanılarak yazılmış bir unit test ve Cypress kullanılarak yazılmış bir uçtan uca test senaryosu üzerinde AAA pattern’in uygulama pratiklerini inceleyelim.
<pre>test('show textfield error', () =&gt; { // arrange render(&lt;Textfield maxLength="3" data-testid="textfield" /&gt;) // act fireEvent.change(screen.getByTestId('textfield'), { target: { value: 'foobar' } }); // assert expect(screen.getByText('Input should not be more than 3 characters')).toBeInDocument() expect(screen.getByTestId('textfield')).toHaveValue("foo") })</pre>
Üstteki örneğin arrange bölümünde, daha önce yazılmış Textfield isimli bir React component’i maxLength ve testId değerleriyle birlikte React Testing Library kütüphanesinin render metodu aracılığıyla render ediliyor. Akabinde act bölümünde Textfield component’inin sağladığı input’a, maxLength ile tanımlanan değerden fazla sayıda karaktere sahip bir metin girişi yapılıyor. Son olarak assert bölümünde ise girilen değerin karakter sayısının, maxLength ile tanımlanan maksimum karakter sayısını aştığı bilgisinin kullanıcıya gösterildiği ve kullanıcının girdiği metnin izin verilen kadarının input içerisine yazılıp kalanının göz ardı edildiği iddia ediliyor.
<pre>it('show login error', () =&gt; { // arrange cy.visit('https://foo.bar/login') // act cy.get('button').contains('Exist user').click() cy.get('input[type="email"]').type('foo@bar.com') cy.get('input[type="password"]').type('foobar') cy.get('button').contains('Login').click() // assert cy.contains('The username or password is incorrect').should('be.visible') })</pre>
Cypress kütüphanesi kullanılarak yazılan diğer örnekte ise arrange bölümünde bir web uygulamasının kullanıcı giriş sayfası açılıyor. Akabinde act bölümünde rastgele yazılmış bir e-posta adresi ve parolayla giriş formu doldurulup gönderiliyor. Assert bölümünde ise bu bilgilerin hatalı olduğu mesajının ekranda son kullanıcıya gösterildiği iddia ediliyor.
<h3>Sonuç</h3>
AAA pattern kullanılırken act bölümündeki etkileşimler değişip çeşitlendikçe assert bölümündeki iddiaların da değişmesi gerekir. Bu sayede yazılan testlerin <a href="https://en.wikipedia.org/wiki/Happy_path">happy path</a>, golden path veya sunny day olarak adlandırılan, yalnızca normal şartlarda gerçekleşmesi beklenen, sonuçları tahmin edilen senaryoları içermesinin önüne geçilebilir.
Konuyu özetlemek gerekirse; React Testing Library kütüphanesi kullanılarak yazılan unit test örneğinde, Textfield component’i, input’a maxLength ile tanımlanan değerden az veya eşit karakter sayısına sahip bir metin girişi yapıldığında farklı bir davranış gösterecekti. Yine benzer şekilde, Cypress kütüphanesi kullanılarak yazılan uçtan uca test örneğinde, kullanıcı giriş bilgileri forma doğru şekilde girildiğinde uygulama bambaşka bir arayüzle çalışmasına devam edecekti. Bu davranışları birbirinden bağımsız çalışacak şekilde ayrı ayrı ele almak, code / behavioral coverage olarak adlandırılan uygulamanın test kapsamını genişletecek ve uygulama içerisinde gerçekleşmesi ihtimal olan daha fazla durumu kontrol altına alacaktır.
Kullanıcı deneyimi (UX) süreçlerinde, kullanıcı hikâyeleri (user story) önemli bir yer tutar ve her kullanıcının kendine has bir kullanım senaryosu olduğu fikri benimsenir. Bir uygulama parçası geliştirilirken belli bir amaca yönelik geliştirilse de son kullanıcı o amaca ulaşana kadar başarılı olup olmamasından bağımsız olarak birden fazla yolu deneyebilir. O yüzden yazdığımız testlerdeki act bölümlerini ne kadar çeşitlendirirsek o kadar çok kullanım senaryosuna temas etmiş ve uygulamanın o kadar çok farklı noktasını test etmiş oluruz.
<h3>Kaynaklar</h3>
<ul>
<li><a href="https://learn.cypress.io/cypress-fundamentals/how-to-write-a-test">https://learn.cypress.io/cypress-fundamentals/how-to-write-a-test</a></li>
<li><a href="https://medium.com/ranorex-webtestit/keeping-your-test-code-squeaky-clean-with-the-arrange-act-assert-aaa-pattern-883371cffc8e">https://medium.com/ranorex-webtestit/keeping-your-test-code-squeaky-clean-with-the-arrange-act-assert-aaa-pattern-883371cffc8e</a></li>
<li><a href="https://medium.com/@pjbgf/title-testing-code-ocd-and-the-aaa-pattern-df453975ab80">https://medium.com/@pjbgf/title-testing-code-ocd-and-the-aaa-pattern-df453975ab80</a></li>
<li><a href="https://uxplanet.org/user-personas-scenarios-user-stories-and-storyboards-whats-the-difference-cf00315f0799">https://uxplanet.org/user-personas-scenarios-user-stories-and-storyboards-whats-the-difference-cf00315f0799</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=29c8ade89ca1" width="1" height="1" alt=""><hr>
<a href="https://medium.com/akbank-teknoloji/aaa-arrange-act-assert-pattern-kullanarak-test-yazmak-29c8ade89ca1">AAA (Arrange, Act, Assert) Pattern Kullanarak Test Yazmak</a> was originally published in <a href="https://medium.com/akbank-teknoloji">Akbank Teknoloji</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

AAA (Arrange, Act, Assert) Pattern Kullanarak Test Yazmak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/720/1*xyDtc_Rz1pV6WxNziTpF9A.jpeg"></figure>React Testing Library, React bileşenlerini ve bu bileşenlerin davranışlarını test etmek için, son yıllarda oldukça yaygın şekilde kullanılan test kütüphanelerinden bir tanesi. Aslında React Testing Library, DOM Testing Library isimli çekirdek kütüphane üzerine inşa edilmiş, içerisine eklenen kullanışlı API’lar aracılığıyla React bileşenleriyle çalışmak için özelleştirilmiş bir kütüphane. Benzer şekilde farklı framework’lerle birlikte çalışabilen <a href="https://testing-library.com/docs/vue-testing-library/intro/">Vue Testing Library</a>, <a href="https://testing-library.com/docs/angular-testing-library/intro">Angular Testing Library</a>, <a href="https://testing-library.com/docs/svelte-testing-library/intro">Svelte Testing Library</a> gibi kütüphaneler de bulunmakta.
<h3>Motivasyon</h3>
JavaScript uygulamalarını ve React bileşenlerini test etmek için önceleri birçok farklı popüler kütüphane kullanılıyordu. <a href="https://mochajs.org/">Mocha</a>, <a href="https://jasmine.github.io/">Jasmine</a>, <a href="https://enzymejs.github.io/enzyme/">Enzyme</a> bunlardan bazıları. Fakat ne oldu da Testing Library onlardan ayrıldı?
Testing Library’i geliştiren <a href="https://github.com/orgs/testing-library/people">ekip</a>, geliştiricilerin yazdıkları birim testlerin, uygulamanın kendisine dair çok fazla iş bilgisi içerdiğini ve bu nedenle de yazılan testlerin davranış olarak son kullanıcıdan ziyade geliştiricilerin reflekslerine yakın olduğunu söylüyordu. JavaScript ve React ekosistemine aşina olanların yakından tanıdığı Kent C. Dodds’ın 2018 senesinde attığı tweet’deki şu söz adeta kütüphanenin de mottosu oldu.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/579/1*wDSZFFqva4C5LdJIDO5Z-A.jpeg"><figcaption><a href="https://twitter.com/kentcdodds/status/977018512689455106">https://twitter.com/kentcdodds/status/977018512689455106</a></figcaption></figure>Kent C. Dodds, yazılan testlerin, uygulamayı kullanacak son kullanıcıların davranışlarına ne kadar benzerse o kadar güvenilir olabileceğinden bahsediyordu. Bu sayede, yazılan testlerin uygulamaya kod katmanında değil deneyim olarak bağlı olacağından, bakımı daha kolay, kod katmanında yapılacak değişikliklere karşı daha az kırılgan ve uzun ömürlü yani sürdürülebilir olacağını savunuyordu.
<h3>Örnek Senaryo</h3>
Basit bir örnek düşünelim. Bir web uygulamasına giriş yapmamızı sağlayacak forma ait bileşenleri test ettiğimizi varsayalım. En basit hâliyle kullanıcıdan iki adet girdi alacak metin kutusuna ve formu iletecek bir buton bileşenine ihtiyacımız var. Geleneksel metodolojilerle birim testler yazıyor olsaydık bu bileşenlere ekseriyetle CSS veya XPath seçicileri üzerinden erişecektik. Bir süre sonra uygulamanın davranışında bir değişiklik olmasa dahi kaynak kodunda yapılacak en ufak bir seçici değişikliği testlerimizin bozulmasına neden olacaktı.
Fakat bu testi bir son kullanıcı gözünden yazmış olsaydık, kullanıcı, üzerinde “kullanıcı adınız” yazan metin kutusuna kullanıcı adını, “parolanız” yazan metin kutusuna parolasını yazacak ve yine üzerinde “giriş yap” yazan butona tıklayarak uygulamaya giriş yapmayı bekleyecekti. Uygulamaya dair hiçbir ek bilgiye ihtiyaç duyulmayacaktı.
Testing Library ve onu temel alan diğer kütüphaneler geleneksel metodolojileri de desteklemekle birlikte geliştiricilere bu şekilde kullanıcı odaklı birim testler yazdırmayı amaçlıyor.
<h3>İlk Test</h3>
React Testing Library, bir test framework’ü veya test runner’ı olmadığı için yazılan testleri çalıştırabilmek için Jest vb. bir test runner uygulamasına ihtiyaç duyuyor. Jest olmadan kullanımı <a href="https://testing-library.com/docs/react-testing-library/setup/#using-without-jest">mümkün olsa da</a> topluluk Jest’i kullanmayı öneriyor. Eğer testlerini yazacağınız React uygulamasını, Create React App vb. bir şablon (boilerplate) üzerinden kurduysanız büyük ihtimalle gerekli test ortamı yapılandırmaları ve örnek testler projeniz içerisinde yer alacaktır. Sıfırdan kurulum yapacaksanız eğer ihtiyacınız olan paketleri seçerek kurmanız ve yapılandırmalarıyla ayrıca ilgilenmeniz <a href="https://testing-library.com/docs/react-testing-library/intro/">gerekecek</a>.
İlk test için yukarıda bahsettiğimiz giriş formundaki buton bileşenini ele alalım. Gerçek hayat senaryolarında pek karşılığı olmasa da çalışma prensibini anlayabilmek adına buton bileşeninin dışarıdan text ve message isminde iki değer aldığını, üzerinde text değeri yazan butona tıklanıldığında ise ekranda message değerinin gösterildiğini varsayalım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/720/1*FnCdzLsGsp9o0JxZkMVKEg.jpeg"><figcaption>button.test.js</figcaption></figure>Test senaryosunun akışı, son kullanıcının uygulamayı kullanırken yaşadığı deneyime çok benzediği için her ne kadar kendisini açıklasa da yine adım adım üzerinden geçelim.
<ul>
<li>İlk olarak render metodu sayesinde, test dosyamıza import ettiğimiz buton bileşenini tıpkı bir React uygulaması içerisinde kullanılıyormuş gibi render ettik.</li>
<li>Akabinde click, keyDown, change, drop gibi kullanıcı etkileşimlerini simüle edebileceğimiz fireEvent objesinin click metoduyla üzerinde “foo” yazan butona tıkladık.</li>
<li>Son olarak da kullanıcının gördüğü arayüze tekabül eden screen objesi içerisindeki getByText metoduyla “bar” metninin ekranda görünür olup olmadığını kontrol ettik.</li>
</ul>
Bu üç adımlı test yazma sürecine AAA yani Arrange, Act, Assert pattern ismi veriliyor. İlk olarak test edilecek ortamı hazırlıyor, sonrasında bu ortamla birtakım etkileşimlere giriyor ve nihayetinde bu etkileşimler neticesinde kimi iddialarda bulunarak testi tamamlıyoruz.
<h3>Sonuç</h3>
Testing Library, son kullanıcının davranışlarını simüle etmek için birçok farklı <a href="https://testing-library.com/docs/queries/about">query</a> ve <a href="https://testing-library.com/docs/dom-testing-library/api-events">event</a>’i çekirdek kütüphanesinde barındırıyor. Yazılacak testin ihtiyacına göre bu özellikleri yine topluluk tarafından geliştirilen <a href="https://github.com/testing-library/user-event">eklentilerle</a> zenginleştirmek mümkün. React Testing Library de çekirdek kütüphaneden aldığı yeteneklerle, geliştiricilere React bileşenlerini test etmenin pratik ve sürdürülebilir bir yöntemini sunuyor.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://testing-library.com/">https://testing-library.com</a></li>
<li><a href="https://testing-library.com/docs/react-testing-library/intro">https://testing-library.com/docs/react-testing-library/intro</a></li>
<li><a href="https://twitter.com/kentcdodds/status/977018512689455106">https://twitter.com/kentcdodds/status/977018512689455106</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=98d267f4f026" width="1" height="1" alt=""><hr>
<a href="https://medium.com/akbank-teknoloji/react-testing-library-ile-kullan%C4%B1c%C4%B1-odakl%C4%B1-birim-testler-yazmak-98d267f4f026">React Testing Library ile Kullanıcı Odaklı Birim Testler Yazmak</a> was originally published in <a href="https://medium.com/akbank-teknoloji">Akbank Teknoloji</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

React Testing Library ile Kullanıcı Odaklı Birim Testler Yazmak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*PFclmfwyFgS9NLfjFdk4HA.jpeg"></figure><blockquote>Axios serisindeki bir önceki yazı: <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-4-localforage-ile-http-yan%C4%B1tlar%C4%B1n%C4%B1-indexeddbde-%C3%B6nbelleklemek-c246ebf6d8f8">Axios İpuçları #4: localForage ile HTTP Yanıtlarını IndexedDB’de Önbelleklemek</a>
</blockquote>
Axios Mock Adapter, Axios ile yapılan HTTP isteklerini mocklamak için kullanılan, oldukça popüler bir kütüphane. Peki neden böyle bir kütüphaneye ihtiyaç duyuyoruz?
<h4>Motivasyon</h4>
Ekseriyetle, birim testler yazarken bir API’a yapılan isteğin döndüğü yanıtla değil, yanıtın ve varsa hata durumlarının doğru şekilde ele alınıp alınmadığıyla ilgileniyoruz. Hâl böyle olunca, gerçek zamanlı olarak bir API’a istek yapmak ve yanıtını beklemek, belki günde defalarca çalıştırılacak bir birim test için gereksiz zaman ve kaynak kullanımına neden oluyor.
Bunun önüne geçmek için yapmak istediğimiz isteğin yanıtına bir <a href="https://en.wikipedia.org/wiki/Method_stub">stub</a> yerleştirebiliyoruz. Stub’ı, bizi API’ın gerçek ortamından izole eden, fakat uygulamamızın, API’dan yanıt almışçasına beklenen davranışını göstermeye devam etmesini sağlayan ön tanımlı veriler olarak düşünebiliriz.
Bir örnek yapalım. Hâlihazırda Axios kullandığımız projeye Axios Mock Adapter’ı bir geliştirme ortamı bağımlılığı olarak dâhil edelim.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*HlbsvMW-_X4STMeGT9v5yg.png"></figure>Sözde API’ımıza basit bir istek yaparak sipariş verilerini alalım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Qhc0c99bt0PUU3TP13qD7w.png"></figure>Akabinde Axios Mock Adapter’ı olaya müdahil edelim ve az önce sipariş verilerini almak için kullandığımız API ucuna farklı sipariş bilgileriyle bir stub ekleyelim.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*GcPh2B7sAazY1yfiwF18hg.png"></figure>Çıktıdan görüleceği üzere varsayılan Axios instance’ına yapılan GET isteklerinin, oluşturduğumuz stub ile 200 OK dönmesini sağlamış olduk. Uygulamamızın koduna herhangi bir müdahalede bulunmadık. Dahası API’ımıza hiçbir istek ulaşmadı ve HTTP isteğinin yanıt vermesi milisaniyeler sürdü.
Axios Mock Adapter’ın yetenekleri yalnızca bununa sınırlı değil elbette. Kısaca özetlemek gerekirse;
<ul>
<li>
reply özelliğiyle POST, PUT gibi diğer HTTP metotlarını ve 404, 500 gibi diğer HTTP durumlarını da mocklayabilme,</li>
<li>
replyOnce özelliğiyle tek seferlik mocklar oluşturabilme,</li>
<li>
onAny özelliğiyle bir API ucunu her HTTP metotu için mocklayabilme,</li>
<li>
Network hatası ve timeout senaryolarını simüle edebilme,</li>
<li>
Zincirleme mock özelliğiyle arka arkaya mocklar tanımlayabilme,</li>
<li>
delayResponse özelliğiyle isteklere bekleme süreleri tanımlayabilme,</li>
<li>
passThrough özelliğiyle gerçek API’a erişebilme.</li>
</ul>
<h4>Sonuç</h4>
Diğer tüm kullanışlı özelliklerinin yanı sıra, yalnızca en basit reply özelliği dahi gündelik hayattaki birçok senaryoyu simüle etmeye yetiyor Axios Mock Adater’ın. Meraklısı için <a href="https://github.com/axios/moxios">Moxios</a> adında bir alternatifi de mevcut.
<h4>Kaynaklar</h4>
<ul><li><a href="https://github.com/ctimmerm/axios-mock-adapter">https://github.com/ctimmerm/axios-mock-adapter</a></li></ul>
<blockquote>Axios serisindeki bir sonraki yazı: <a href="https://tugsanunlu.medium.com/axios-i%CC%87pu%C3%A7lar%C4%B1-6-http-i%CC%87steklerinde-upload-download-bilgilerini-yakalamak-395aaaa8d135">Axios İpuçları #6: HTTP İsteklerinde Upload/Download Bilgilerini Yakalamak</a>
</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=4b2c586f4ae1" width="1" height="1" alt="">

Axios İpuçları #5: Axios Mock Adapter ile HTTP İsteklerini Mocklamak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ciJVITIHboZqGVlyrmuU6g.png"></figure><blockquote>Cypress serisindeki bir önceki yazı: <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-4-http-i%CC%87stekleri-yapmak-901a5cd2a69e">Cypress İpuçları #4: HTTP İstekleri Yapmak</a>
</blockquote>
<h4>Recorder</h4>
Google Chrome, kullanıcıların, web sayfaları üzerindeki etkileşimlerini kaydetmelerini ve daha sonra bu kayıtlar üzerinden performans ölçümleri yapmalarını sağlayan aracı <a href="https://developer.chrome.com/docs/devtools/recorder/">Recorder</a>’ı geçtiğimiz aylarda <a href="https://developer.chrome.com/docs/devtools/">DevTools</a>’a <a href="https://developer.chrome.com/blog/new-in-devtools-97/#recorder">eklemişti</a>. Bu araç sayesinde spesifik senaryolar özelindeki akışların render performanslarını incelemek ve gerekiyorsa iyileştirmeler yapmak daha pratik hâle geldi.
<a href="https://medium.com/media/85e8c9e392a30fbf25f58450ec473507/href">https://medium.com/media/85e8c9e392a30fbf25f58450ec473507/href</a>Recorder’ın beraberinde getirdiği bir özellik de kaydedilen kullanıcı akışlarını farklı formatlarda dışarı aktarabiliyor olmasıydı. Bu sayede kullanıcı akışlarının üçüncü parti uygulamalarla paylaşılabilmesinin önü açılmış oldu.
Daha önce bir başka uçtan uca test çözümü olan <a href="https://github.com/puppeteer/puppeteer">Puppeteer</a> için bir araç <a href="https://github.com/puppeteer/replay">duyurulmuştu</a>. Geçtiğimiz hafta ise Recorder ile kaydedilen kullanıcı akışlarının, Cypress test senaryolarına dönüştürülmesini sağlayan <a href="https://github.com/cypress-io/cypress-chrome-recorder">Cypress Chrome Recorder</a>’ın ilk sürümü topluluk tarafından <a href="https://github.com/cypress-io/cypress-chrome-recorder/releases">yayımlandı</a>.
<h4>Akış Kaydetmek</h4>
Basit bir örnek yapalım. Amazon web sitesindeki kullanıcı oturum açma akışını Recorder ile kaydedelim.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*iaxvMtmhTrmuM5J2MfrOKw.png"><figcaption>Kayda başlamak</figcaption></figure>Kabaca aşağıdaki gibi görünen bir akışımız olacak.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*8A9bF5FdZn809fJOM9rF8g.gif"><figcaption>Örnek akış</figcaption></figure>Daha sonra kaydettiğimiz akışı JSON formatında dışarı aktaralım. Daha önce akışları yalnızca JavaScript formatında içeri ve dışarı aktarma imkânı varken <a href="https://developer.chrome.com/blog/new-in-devtools-101/">Chrome 101</a> sürümünden itibaren JSON formatı da desteklenmeye başladı.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WLUY4zdMEtg3Yu0-fh9tLQ.png"><figcaption>Akışın JSON olarak dışarı aktarılması</figcaption></figure>Test ortamımıza dönelim. Bu aşamada Cypress’in hâlihazırda kurulu ve yapılandırılmış olduğunu varsayıyoruz. Kurulu değilse <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-1-ortam-tan%C4%B1mlamak-ve-ortam-de%C4%9Fi%C5%9Fkenleri-kullanmak-374099ac8603">buradan</a> yardım alınabilir.
İlk olarak @cypress/chrome-recorder paketini kuralım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Z2Kbg0FZPNLOIyxk6KqNUQ.png"><figcaption>Cypress Chrome Recorder’ın kurulması</figcaption></figure>Akabinde Recorder’dan dışarı aktardığımız akış dosyasını recordings dizini altına kopyalayalım ve kurduğumuz pakete argüman olarak verip çalıştıralım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*RxyGm3-nki-xiXbfPF7cIQ.png"><figcaption>Cypress Chrome Recorder’ın çalıştırılması</figcaption></figure>Birkaç saniye içerisinde test senaryolarımızın olduğu integration dizini altında JSON dosyasıyla aynı isimde bir test dosyası oluşacak.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/400/1*C-3JPyeyLtGLjl0qvB1ImA.png"><figcaption>Test senaryosunun oluşturulması</figcaption></figure>Dosyayı açıp incelediğimizde ise Recorder ile Amazon’dan aldığımız akış kaydının CSS seçicilerinden, girilen input değerlerine kadar tanımlanmış ve koşturulmaya hazır bir Cypress senaryosuna dönüştüğünü göreceğiz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6gY1L7IKpZS4QM2LsNa1PA.png"><figcaption>Oluşturulmuş örnek senaryo</figcaption></figure><h4>Sonuç</h4>
Cypress Chrome Recorder elbette her zaman dört başı mamur bir çıktı vermiyor. Özellikle DOM ağacının kalabalık olduğu sayfalarda ve uzun akışlarda doğru şekilde çalışan senaryolar oluşturmasına rağmen seçicileri pek okunabilir olmuyor. Fakat işçilik konusunda neredeyse tüm yükü kendi üzerine alıyor. Alametifarikası da bu zaten bence. Testi yazan kişiye sadece oluşturulan çıktıya müdahale edip iyileştirmek kalıyor.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://github.com/cypress-io/cypress-chrome-recorder">https://github.com/cypress-io/cypress-chrome-recorder</a></li>
<li><a href="https://twitter.com/ChromeDevTools/status/1518968141061181442?cxt=HHwWhMCykb_eupQqAAAA">https://twitter.com/ChromeDevTools/status/1518968141061181442?cxt=HHwWhMCykb_eupQqAAAA</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=fb6add3e8238" width="1" height="1" alt="">

Cypress İpuçları #5: Chrome DevTools Recorder ile Test Senaryoları Oluşturmak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*caomcLp-9-y7K_oBKpHC7w.jpeg"></figure><blockquote>
Cypress serisindeki bir önceki yazı: <a href="https://medium.com/@tugsanunlu/cypress-i%CC%87pu%C3%A7lar%C4%B1-3-custom-command-tan%C4%B1mlamak-f1d95c8949fd">Cypress İpuçları #3: Custom Command Tanımlamak</a>
</blockquote>
<h4>Motivasyon</h4>
Cypress ile uçtan uca testler yazarken kimi zaman test senaryoları içerisinde HTTP istekleri yapmamız gerekebiliyor. Yine bir gerçek hayat senaryosu üzerinden gidelim. E-ticaret sitemizde bir üye kayıt formu olduğunu ve bu formun doğru şekilde doldurulup gönderildiği takdirde üye kaydının yapılıp yapılmadığını test ettiğimizi varsayalım.
Bu testi yazmaya başladığımızda kabaca iki sorun çıkacak karşımıza.
<ol>
<li>Testimiz her çalıştığında sistemde yeni bir kullanıcı yaratılacak. Daha önce kayıt olan kullanıcıyı aynı bilgilerle tekrar yaratamayacağımız için ikinci defa çalıştırdığımızda, kayıt fonksiyonları doğru şekilde çalışıyor olsa dahi testimiz başarısız olacak. Yani deterministik olmayacak. Bunun önüne geçmek için elimizde çok sayıda kullanıcı bilgisi içeren bir havuz bulundurabilir veya <a href="https://github.com/faker-js/faker">faker.js</a> gibi kütüphanelerle anlık sahte kullanıcı bilgileri oluşturabiliriz. Fakat her iki durumda da bir sonraki sorunun oluşmasına engel olamayız.</li>
<li>Kirli veri oluşması. Testi her çalıştırdığımızda sistemde atıl şekilde duran bir kullanıcı yaratmış olacağız ve bu kullanıcıların sayısı her geçen gün giderek artacak, artacak ve artacak.</li>
</ol>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/480/0*AdfpboMz0BmWjBxP.gif"></figure>Bunun önüne geçmek için testler sonucunda oluşan kirli veriyi belirli periyotlarla temizlemeye ihtiyacımız var. Kullanılan en yaygın pratik ise bunu bir API marifetiyle tek tek veya toplu olarak yapmak.
Yerleşik HTTP İstemcisi: Request
API üzerinde /api/test-data ucu olduğunu varsayalım. Bu uca yapılan DELETE istekleri kirli veriyi temizliyor olsun. Normal şartlarda Cypress, Node.js üzerinde koştuğu için bu HTTP isteğini <a href="https://github.com/axios/axios">axios</a>, <a href="https://github.com/node-fetch/node-fetch">node-fetch</a> gibi kütüphaneler aracılılığıyla ya da söz dizimi diğerlerine göre biraz daha karmaşık olarak standart <a href="https://nodejs.dev/learn/making-http-requests-with-nodejs/#perform-a-get-request">https</a> modülüyle yapmak gerekecekti. Fakat Cypress, içerisinde <a href="https://github.com/request/request">request</a> kütüphanesinin bir <a href="https://github.com/cypress-io/request">fork’unu</a> bulunduruyor. Bu sayede ek bir kurulum yapmadan pratik şekilde HTTP istekleri <a href="https://docs.cypress.io/api/commands/request">yapabiliyoruz</a>.
İlk olarak kirli veriyi temizleyecek HTTP isteğini <a href="https://medium.com/@tugsanunlu/cypress-i%CC%87pu%C3%A7lar%C4%B1-3-custom-command-tan%C4%B1mlamak-f1d95c8949fd">bir önceki yazıda bahsettiğimiz şekilde</a> custom command hâline getirelim ki tekrar tekrar kolayca kullanabilelim. İsteğimiz oldukça basit. Sadece yetkilendirme için tek bir authorization header’ımız var.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*LE8FPTXJambqRpGZnYA9ZA.png"><figcaption>custom command tanımlanması</figcaption></figure>Artık oluşturduğumuz custom command’i test senaryosu içerisinde kullanabiliriz. Cypress’in sağladığı after() hook’u sayesinde clearDirtyData() metodunun tüm test blokları başarılı olduktan sonra çağrılması gerektiğini belirtebiliyoruz. Kullanım tercihine göre before() hook’unu kullanarak teste başlamadan önce de kirli verileri temizleyebilirdik.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Q1hfA0gWdAB1OMn1WMiiYg.png"><figcaption>tanımlanan custom command’in test senaryosunda kullanılması</figcaption></figure><h4>Sonuç</h4>
Bu senaryo özelinde, elimizde sisteme kaydedilecek tek bir kullanıcı bilgisi olsa dahi kayıt fonksiyonlarını istediğimiz kadar test edebilir durumdayız. Test sonuçlarını bir kaynağa raporlamak, başarısız olan testler için alarm sistemleri oluşturmak, test senaryoları içerisinde HTTP istekleri yapmamızı gerektirecek diğer senaryolara örnek olarak verilebilir.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://github.com/cypress-io/request">https://github.com/cypress-io/request</a></li>
<li><a href="https://docs.cypress.io/api/commands/request">https://docs.cypress.io/api/commands/request</a></li>
</ul>
<blockquote>Cypress serisindeki bir sonraki yazı: <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-5-chrome-devtools-recorder-ile-test-senaryolar%C4%B1-olu%C5%9Fturmak-fb6add3e8238">Cypress İpuçları #5: Chrome DevTools Recorder ile Test Senaryoları Oluşturmak</a>
</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=901a5cd2a69e" width="1" height="1" alt="">

recent blog posts