<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>
<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="">

Cypress İpuçları #4: HTTP İstekleri Yapmak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*prc4AD7kZMGjhO7u7G2ZFA.jpeg"></figure><blockquote>
Axios serisindeki bir önceki yazı: <a href="https://medium.com/@tugsanunlu/axios-i%CC%87pu%C3%A7lar%C4%B1-3-lru-cache-ile-http-yan%C4%B1tlar%C4%B1n%C4%B1-%C3%B6nbelleklemek-4ecbf40434d0">Axios İpuçları #3: LRU Cache ile HTTP Yanıtlarını Önbelleklemek</a>
</blockquote>
<h4>Motivasyon</h4>
Daha önce, Axios istemcisiyle yapılan HTTP isteklerinin yanıtlarını istemci üzerinde önbelleklemeye dair bir yazı <a href="https://medium.com/@tugsanunlu/axios-i%CC%87pu%C3%A7lar%C4%B1-3-lru-cache-ile-http-yan%C4%B1tlar%C4%B1n%C4%B1-%C3%B6nbelleklemek-4ecbf40434d0">yazmıştım</a>. O yazıda bahsettiğim yöntem, <a href="https://en.wikipedia.org/wiki/Cache_replacement_policies">LRU cache</a> algoritmasını kullanmakta ve HTTP yanıtlarını <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage">session storage</a>’da saklamaktaydı.
Gerek session storage’da en fazla 5MB veri saklanabilmesi gerek de aktif tarayıcı sekmesi kapandığında session storage’daki verilerin sıfırlanması hasebiyle bu yöntem kısıtlı kullanım senaryolarında geçerliydi. SPA ve mobil uygulamalar gibi, istemci üzerinde render edilip (CSR) aynı oturumda hayatına devam eden uygulamalar için iyi bir çözüm sunarken sunucuda render edilen (SSR) ve/veya daha büyük boyutlu verilerin önbelleklenmesi gereken uygulamalarda yetersiz kalıyordu.
Bu yazıda buna alternatif olarak Axios ile IndexedDB üzerinde nasıl önbellekleme yapılacağından bahsedeceğim.
<h4>IndexedDB</h4>
IndexedDB, istemci cihazlarında anahtar-değer (key-value pair) çiftleri formatında veri saklamaya olanak tanıyan bir web API’ı. Başka bir deyişle tarayıcı içerisinde tutulan bir NoSQL veritabanı aslında. <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies">Cookie</a>, <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage">local storage</a>, <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage">session storage</a> gibi diğer çözümlerin aksine sabit bir veri saklama kapasitesi yok. İstemci diskindeki boş alan ve kullanılan tarayıcının yeteneklerine göre değişkenlik gösteriyor. İstisnalar olmakla birlikte kabaca istemci diskindeki boş alanın %50'si kadar bir depolama alanını IndexedDB <a href="https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria#storage_limits">kullanabiliyor</a>. Bu alan dolduğunda ise en az kullanılandan başlanarak önbellekler birer birer siliniyor.
<h4>localForage</h4>
IndexedDB’nin tarayıcıda veri saklayabilen diğer yöntemlerden bir farkı da asenkron olarak çalışması. Örneğin local storage’a yapılan okuma ve yazma işlemleri senkrondur. Geliştirdiğimiz uygulama içerisinde local storage’a bir veri yazıyoruz diyelim. Bu veri yazma işlemi tamamlanana kadar uygulama geçici olarak bloklanır ve yazma işlemi tamamlandığında kaldığı yerden çalışmaya devam eder. Bunu o kadar hızlı bir şekilde yapar ki ne uygulamada bir aksama yaşanır ne de son kullanıcı duraklamayı fark eder.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/249/0*BHP-T7b3M6gw80Fw"><figcaption>localForage</figcaption></figure>Fakat IndexedDB büyük boyuttaki verileri bir veritabanı gibi yönettiğinden doğası gereği farklıdır. Veritabanı oluşturmak, veritabanına bağlanmak, veri yazmak, veri okumak gibi işlemler API’ın sağladığı <a href="https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API#interfaces">interface</a>’ler aracılığıyla asenkron olarak yapılır. Fakat bu da beraberinde implementasyon zorluklarını getirir. Bu nedenle MDN dâhil olmak üzere birçok kaynak, IndexedDB operasyonlarını daha pratik kütüphaneler aracılığıyla yapmayı <a href="https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API#see_also">önerir</a>. İsminden anlaşılacağı gibi, IndexedDB’i local storage kolaylığında kullanmayı amaçlayan <a href="https://github.com/localForage/localForage">localForage</a>, bu kütüphanelerden en yaygın olanı. Kullanılan tarayıcıların yeteneklerine göre muhtelif polyfill çözümlerini de içeriyor.
<h4>Axios ile localForage Kullanımı</h4>
Sıra geldi Axios, IndexedDB ve localForage üçlüsünü birlikte kullanmaya. İlk olarak bağımlılıkları kuralım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*C3vw_HVfS_5sXSK106Oksg.png"><figcaption>NPM ile bağımlıkların kurulması</figcaption></figure>Akabinde localforage için bir store oluşturalım. Bu store içerisinde localforage instance’ı yaratıyoruz. IndexedDB için kullanacağımız veritabanı adını ve driver bilgisini bu instance içerisinde tanımlıyoruz. Hemen yukarıda bahsettiğim polyfill çözümü burada karşımıza çıkıyor. Driver seçimi için birincil olarak IndexedDB’i, ikincil olarak ise local storage’ı belirtiyoruz. Kullanıcılar, IndexedDB’nin desteklenmediği bir tarayıcı kullanıyorlarsa uygulamanın akışı hiç bozulmadan veritabanı olarak local storage kullanılmaya başlanıyor. Son olarak HTTP yanıtlarının ne kadar süreyle önbellekleneceğini belirtip yarattığımız localforage instance’ının Axios ile eşleşmesini <a href="https://www.npmjs.com/package/axios-cache-adapter">axios cache adapter</a> marifetiyle sağlıyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ihEZg-GmgvO4j-JqZ2Vhuw.png"><figcaption>localforage için store oluşturulması</figcaption></figure>Uygulama içerisinde, her tıklandığında GitHub’ın public API’larından istenilen kullanıcı bilgilerini getiren basit bir buton olduğunu varsayalım. Normal şartlarda GitHub API’ına yapacağımız HTTP isteğini, az önce oluşturduğumuz localforage instance’ı ile sarmalıyoruz. Bu sayede GitHub’a yapılacak HTTP istekleri için bir ara katman oluşturuyoruz. Böylece GitHub’a yapılacak tüm istekler ilk olarak localforage üzerinden geçecek ve isteğin yapılıp yapılmayacağına ve hangi yanıtın verileceğine localforage karar verecek.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*F-jnhMR49UeptC1_1KlmVQ.png"><figcaption>http isteğinin localforage store’u ile sarmalanması</figcaption></figure>Uygulamayı çalıştıralım ve DevTools üzerinden izleyelim.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*gorZS0tThqLEGBsZ3YRIfg.png"></figure>Butona tıklayıp DevTools’daki Network sekmesine baktığımızda HTTP isteğinin GitHub sunucularına yapıldığını ve karşılığında bir yanıt alındığını görüyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*4-44fuOymhL0NJ1xNexD1g.png"><figcaption>ilk http isteği</figcaption></figure>Akabinde Application sekmesindeki Storage &gt; IndexedDB menüsüne baktığımızda githubCacheDB isimli bir veritabanı görüyoruz. Bu veritabanında anahtar (key) olarak seslendiğimiz API ucu, değer (value) olarak da bir obje görüyoruz. Obje içerisinde ise GitHub’dan bize dönen yanıt haricinde bir de zaman damgası (timestamp) var.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*m69j1k7f6lGhkEIm_OKE3w.png"><figcaption>indexeddb içeriği</figcaption></figure>Tekrar uygulamadaki butona bastığımızda GitHub’dan alınan kullanıcı bilgilerinin yine ekrana yazıldığını ama GitHub sunucularına istemcimizden bir HTTP isteği çıkmadığını görüyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*yIvpyUFHk5SiryaSF7ATMA.png"><figcaption>sonraki http istekleri</figcaption></figure>IndexedDB kaydı içerisindeki zaman damgası, GitHub sunucularından HTTP yanıtını aldığımız anın üstüne localforage store’unda tanımladığımız önbellekleme süresinin eklenmiş hâline karşılık geliyor. O zaman dolana kadar aynı API ucuna yapılacak tüm HTTP isteklerinin yanıtları IndexedDB’deki kayıttan verilecek ve GitHub sunucularına yeni bir istek yapılmayacak.
<h4>Sonuç</h4>
Sonuç olarak bir önceki önbellekleme yazısının finalini tekrar etmiş olayım. İlk bakışta çocuksu bir heyecanla her API ucunu önbelleklemek geliştirici olarak içimizden geçse de, hangi API ucunun neden ve ne kadar süreyle önbelleklenmesi gerektiğini ve önbelleklenmediğindeki maliyetini analiz etmeden bu işlere girişmek veri tutarsızlığı ve test zorlukları gibi birçok konu özelinde daha çok baş ağrıtabilir. Son olarak yazıda bahsi geçen basit uygulamayı da paylaşarak <a href="https://github.com/tugsanunlu/axios-localforage">bitireyim</a>.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://localforage.github.io/localForage/">https://localforage.github.io/localForage</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API">https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API</a></li>
<li><a href="https://github.com/tugsanunlu/axios-localforage">https://github.com/tugsanunlu/axios-localforage</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=c246ebf6d8f8" width="1" height="1" alt="">

Axios İpuçları #4: localForage ile HTTP Yanıtlarını IndexedDB’de Önbelleklemek

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Cxs1sa8Kpje96Sb2W2Mu1w.jpeg"></figure><blockquote>Cypress serisindeki bir önceki yazı: <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-2-iframe-ile-%C3%A7al%C4%B1%C5%9Fmak-6ee08316f40c?source=user_profile---------0-------------------------------">Cypress İpuçları #2: Iframe ile Çalışmak</a>
</blockquote>
Bir önceki yazıda, Cypress ile yazılan test senaryonlarında “custom command” kullanılabileceğinden bahsetmiş fakat detayına girememiştim. Bu yazıda çok kısa bir şekilde custom command’a neden ihtiyacımız olabileceğinden ve nasıl tanımlayabileceğimizden bahsedeceğim.
<h4>Motivasyon</h4>
Cypress’in get(), url(), contains() gibi yerleşik tüm yardımcı metotları cy nesnesinde yer alıyor ve test senaryoları içerisinde cy.get() şeklinde nesne notasyonunda kullanılıyor. Cypress’in sunduğu custom command API’ı ile cy nesnesine kendi metotlarımızı ekleyebiliyoruz. Bu sayede hem senaryolar içerisinde tekrar tekrar başvurmamız gereken metotları, Cypress’in yerleşik metotlarının konforunda kullanabiliyoruz hem de okunabilirlik açısından bütünlük sağlamış oluyoruz.
<h4>Yeni Command Tanımlamak</h4>
Örnek olması açısından yeni bir command oluşturalım. Bilindiği üzere cy.get() metodunu sayfalardaki DOM bileşenlerini seçmek için kullanıyoruz. Hâlihazırda bir butonu aşağıdaki gibi birçok farklı yöntemle seçebiliriz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*PZ3dWaJoFLlEPpqXTIy83A.png"></figure>Tüm yöntemlerin kendi içerisinde avantajları ve dezavantajları olmasına rağmen, Cypress dokümanları best practice olarak test senaryoları için ayrılmış özel bir attribute kullanmayı <a href="https://docs.cypress.io/guides/references/best-practices#Selecting-Elements">öneriyor</a>. Bunun en büyük nedeni, id, class gibi CSS seçicilerinin geliştirme sürecinde değişime fazla açık olması. Test için ayrılmış özel bir attribute kullanmak, uygulama arayüzünün tasarımı değişse de test senaryolarının değişikliğe ihtiyaç duymadan hayatına devam edebilmesini sağlıyor.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/480/0*0FIjHTRFLNVHfPVF"></figure>Üstteki seçici karmaşasından sonra ekip olarak data-test isminde bir attribute kullanmaya karar verdik diyelim. Bunu eğer Cypress’in varsayılan get() metoduyla yapmaya kalkarsak her defasında cy.get("[data-test]='submitForm'") şeklinde uzun uzadıya yazmak zorunda kalacağız. Bu belki birkaç seçicinin olduğu kısa test senaryolarında dikkate değer görülmeyebilir ama karmaşık ve uzun senaryolarda can sıkıcı olmaya başlayacaktır. Bunun yerine kendimize özel getByAttr() isminde bir metot tanımlayabilir ve bu kod tekrarlarından kurtulabiliriz.
Yine best practice olarak support dizini altındaki index.js dosyasında veya ona import edilmiş farklı bir dosyada custom command tanımlayabiliriz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*eHuh1OsHHHLEvHPp5BbvZQ.png"><figcaption>support/index.js’de tanımlanan custom command</figcaption></figure>Üstteki command, çok basit bir şekilde Cypress’in yerleşik get() metodunu kullanım senaryomuza göre zenginleştirmiş oldu. Artık bizden yalnızca attribute değerini argüman olarak bekleyen, test senaryolarında doğrudan kullanılmaya hazır getByAttr() isminde bir seçicimiz var.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*-EDCSbMYHEJY6c4QUZZnlg.png"></figure><h4>Sonuç</h4>
Üstteki örnek elbette oldukça basit. Sık kullanılan API istekleri, senaryolarda tekrar eden bloklar, her test öncesinde veya sonrasında çalıştırılmak zorunda olunan operasyonlar bu kapsamda değerlendirilerek custom command hâline getirilebilirler kolayca.
<h4>Kaynaklar</h4>
<ul><li><a href="https://docs.cypress.io/api/cypress-api/custom-commands">https://docs.cypress.io/api/cypress-api/custom-commands</a></li></ul>
<blockquote>Cypress serisindeki bir sonraki 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>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=f1d95c8949fd" width="1" height="1" alt="">

Cypress İpuçları #3: Custom Command Tanımlamak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*IRCoyVrAjIfLfkE5G9Vr8Q.png"></figure><blockquote>
Cypress serisindeki bir önceki yazı: <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">Cypress İpuçları #1: Ortam Tanımlamak ve Ortam Değişkenleri Kullanmak</a>
</blockquote>
Cypress ile uçtan uca test senaryoları yazarken kimi zaman iframe’ler ile çalışmak gerekebiliyor. Modern web uygulamalarında iframe kullanımı pek tercih edilen bir yöntem olmasa da ekseriyetle üçüncü parti servis sağlayıcılarının (oturum yönetimi, reklam gösterimi, analiz takipleri, ödeme araçları vb. servisler) entegrasyonlarında kaçınılmaz olarak iframe’lere başvuruluyor. Elbette Cypress ile iframe’lere erişebiliyoruz fakat sayfa içerisindeki diğer elementlere erişmeye göre biraz meşakkatli oluyor.
<h4>Iframe’e Erişmek</h4>
Test senaryolarında iframe’ler içerisindeki elementlere erişmek için ilk olarak iframe’in document nesnesini yakalamak, sonrasında ise iframe içeriğinin yüklenip yüklenmediğini kontrol etmek gerekiyor. Iframe’e eriştikten sonra ise senaryolarda alışageldiğimiz get() yerine find() metodunu kullanarak iframe içerisindeki istediğimiz elementi seçebiliyoruz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*7LFo7qVTNczSU-Ng5OUHsg.png"><figcaption>iframe içerisindeki elementlere erişmek</figcaption></figure>Üstteki örnekteki getIframeDocument() ve getIframeBody() metotları tüm test senaryolarının erişebileceği ortak bir modülde toplanabilir. Fakat bu her defasında ilgili test senaryosunun içerisinde bir import işlemi yapılacağı anlamına gelir. Bunun yerine Cypress’in <a href="https://docs.cypress.io/api/cypress-api/custom-commands">custom commands</a> özelliği ile cy nesnesine dahil edilebilirler. Bu sayede cy.getIframe() gibi bir metotla testler içerisinde kolaylıkla çağrılabilirler.
<h4>cypress-iframe NPM Paketini Kullanmak</h4>
Bunun için geliştirilmiş ve Cypress’in de dokümantasyonunda önerdiği <a href="https://www.npmjs.com/package/cypress-iframe">cypress-iframe</a> isimli bir NPM paketi bulunuyor. Topluluk tarafından oldukça rağbet gören bir paket. İçerisinde iframe’lere erişim süreçlerini pratikleştirmek için kullanışlı metotlar mevcut.
Kullanımı ise oldukça basit. İlk olarak ilgili paketi geliştirme ortamı bağımlılığı olarak kuralım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TaeKhPMb3WLxABHLrM4gqg.png"><figcaption>cypress-iframe paketinin kurulması</figcaption></figure>Akabinde ise kullanacağımız test senaryosuna veya tüm test senaryolarında kullanmak istiyorsak support dizinindeki index.js dosyasına kütüphaneyi import edelim.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NyxCi1q1Bi5dKAKBkLwc2g.png"><figcaption>cypress-iframe paketinin sağladığı metotlarla iframe’e erişmek</figcaption></figure>Böylece test senaryoları içerisinde kullanabileceğimiz cy.frameLoaded() ve cy.iframe() isimli iki metota sahip oluyoruz. Bunlar kabaca ilk örnekteki getIframeDocument() ve getIframeBody() metotlarına karşılık geliyorlar.
cy.iframe() metodu cy.frameLoaded() metodunda belirtilen iframe’e erişim sağlıyor. Yine ilk örnekteki kontroller de cy.frameLoaded() metodu içerisinde yapılıyor. Her iki metot da senaryo yazımı sırasında Cypress içerisindeki yerleşik bir çözüm gibi ele alınıyor.
<h4>Sonuç</h4>
Özellikle dokümantasyonun dikkatle okunmadığı durumlarda ezbere bilgilerle bu gibi istisnalar üzerinde çalışmak epey zaman kaybettirebiliyor. Acı tecrübelerle sabit maalesef. O nedenle bunun gibi gündelik hayat ihtiyaçlarına dair Cypress ile ilgili yazmaya devam etmek niyetindeyim.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://www.cypress.io/blog/2020/02/12/working-with-iframes-in-cypress/">https://www.cypress.io/blog/2020/02/12/working-with-iframes-in-cypress/</a></li>
<li><a href="https://gitlab.com/kgroat/cypress-iframe">https://gitlab.com/kgroat/cypress-iframe</a></li>
</ul>
<blockquote>
Cypress serisindeki bir sonraki yazı: <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-3-custom-command-tan%C4%B1mlamak-f1d95c8949fd?p=f1d95c8949fd">Cypress İpuçları #3: Custom Command Tanımlamak</a>
</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=6ee08316f40c" width="1" height="1" alt="">

Cypress İpuçları #2: Iframe ile Çalışmak

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*RQ7J5LtA9RbJ4a7tsC5yow.jpeg"></figure><blockquote>Cypress serisindeki bir önceki yazı: <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-0-girizg%C3%A2h-652f6cb5fc60">Cypress İpuçları #0: Girizgâh</a>
</blockquote>
<h4>Motivasyon</h4>
Cypress hakkında girizgâhı <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-0-girizg%C3%A2h-652f6cb5fc60">önceki yazıda</a> yaptığım için bu sefer doğrudan konuya gireceğim. Projelerin ölçeğine ve önemine göre, belirli operasyonları test etmek için yazdığımız uçtan uca test senaryolarını farklı ortamlarda koşturma ihtiyacı duyabiliyoruz.
<h4>Örnek</h4>
Somut örnek vermek gerekirse; Cypress web sitesinin <a href="https://dashboard.cypress.io/login">üye girişi</a> sürecini test eden bir senaryomuz olduğunu düşünelim. Kabaca, ilk olarak kullanıcı Cypress web sitesini açacak. Üye girişi bağlantısına tıklayacak. Daha sonra giriş yöntemini seçecek ve üyelik bilgilerini girerek giriş sürecini tamamlayacak.
Giriş süreçlerinde kimi geliştirmeler yapıldığını varsayalım. Geliştirici, geliştirmeler sonrasında her şeyin doğru çalıştığından emin olmak için üstteki senaryoyu geliştirme yaptığı bilgisayarda (development) test etmek isteyecek. Akabinde bu özelliği yayına çıkmadan evvel QA ekibi de kendi ortamında (testing/QA) test etmek isteyecek. Son olarak ise özellik yayımlandıktan sonra canlı ortamda (production) son kullanıcı testleri yapılacak.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*l7i2jY-qQojDipA7.png"><figcaption>Temsili ortamlar — Görsel: <a href="https://www.miamioh.edu/it-services/news/2017/08/dev-test-prod.html">https://www.miamioh.edu/it-services/news/2017/08/dev-test-prod.html</a></figcaption></figure>Bu testler sırasında önceden yazılan senaryolarda ortama göre görsel bir değişiklik olmayacak. Kullanıcı üyelik bilgilerini girdikten sonra yine aynı butona basacak giriş yapabilmek için. Fakat test esnasında kullanılan veriler değişkenlik gösterecek. Cypress web uygulamasının geliştirme ortamındaki URL’i ile test ortamındaki URL’i farklı olacak. Keza test ortamındaki üyelik bilgileriyle canlı ortamdaki üyelik bilgileri de birbirinden farklı olacak.
Özetle, aynı test senaryolarını farklı ortamlarda farklı verilerle koşturmak için bir çözüme ihtiyacımız olacak. Bu noktada ortam değişkenleri imdadımıza yetişiyor.
<h4>Cypress ve DotEnv</h4>
Pratikte görmek için ilk olarak cypress ve ortam değişkenlerini dosyalar üzerinden yönetmemizi sağlayan dotenv paketlerini kuralım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*t5tzr6IxsD41T4wx-1QdFA.png"><figcaption>NPM bağımlılıklarının kurulması</figcaption></figure>Akabinde Cypress’in test runner ismini verdiği test arayüzünü aşağıdaki komutla başlatabiliriz.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*m6AoOl72k4kld41mBuhpig.png"><figcaption>Cypress runner’ın ilk açılışı</figcaption></figure>Fakat her defasında node_modules altından uzun uzadıya Cypress’e erişmek yerine package.json dosyasına bir script tanımlayabiliriz. Bu script’i tanımlarken env isminde bir argüman beklediğimizi ve gelen bu argümanı TEST_ENV ismindeki ortam değişkenine atayacağımızı belirtelim.
Bu sayede test arayüzünü ayağa kaldırırken aynı zamanda komut satırından alacağımız ortam bilgisini de daha sonra kullanmak üzere saklamış olduk.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*emxHKwGjEzRN_GJNhIJ-aA.png"><figcaption>package.json’da script tanımlama</figcaption></figure>Cypress, eklenti tanımlamalarını konvansiyon olarak plugins dizini altında topluyor. Ortam değişkeni dosyasının seçimini aşağıdaki dotenv yapılandırmasıyla plugins altında sağlayalım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*HxcIM0O2eo6TaCdqHhGMgg.png"><figcaption>plugins/index.js</figcaption></figure>Burada yapılanı özetlemek gerekirse, test arayüzünü ayağa kaldırırken komut satırından bir argüman almış ve TEST_ENV değişkenine atamıştık. Bu yapılandırmada ise Node.js’in ortam değişkeni dosyası olarak .env.TEST_ENV ile argüman olarak belirttiğimiz ortama ait dosyayı dikkate almasını sağladık.
<h4>Ortam Değişkeni Dosyaları</h4>
Temsili olarak yine testlerimizi koşturacağımız üç farklı ortamımız olduğunu varsayalım. .env.development, .env.test ve .env.production ortam dosyalarını projenin ana dizinde oluşturalım ve içlerinde APP_URL isimli, uygulamanın açılacağı URL’i tutan değişkeni tanımlayalım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*7oyY8w62Y2iNgeboObzQIg.png"><figcaption>.env.development</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*UQ3eAJF7G45Kygm90AYGvg.png"><figcaption>.env.test</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*5OE6dR7uqT0bo5evX2L-HQ.png"><figcaption>.env.production</figcaption></figure><h4>Örnek Test Yazmak</h4>
Yalnızca uygulamanın erişilebilir olup olmadığını kontrol edecek ilk test senaryomuzu yazalım. Test içerisindeki Cypress.env metodu, ilgili ortam dosyasındaki APP_URL değişkeninin değerini getirecek.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Xx4vn8Z4B04zYOicl-NvvA.png"><figcaption>integration/open-app.test.js</figcaption></figure><h4>Ortama Göre Testleri Koşturmak</h4>
Yukarıda tanımladığımız script yardımıyla Cypress test arayüzünü production ortam için çalıştıralım.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6TlMzm_wzMubNM3SPwBD6A.png"><figcaption>Test runner’ı ortama göre çalıştırmak</figcaption></figure>Açılan arayüzde proje içerisindeki tüm test senaryoları listelenecek.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*oQVblNOiAssHlFHuEnK0Fg.png"><figcaption>Koşturulacak testin seçimi</figcaption></figure>İstersek spesifik olarak bir testi istersek de tüm testleri sırayla koşturabiliriz. Aynı zamanda bu aşamada testlerin koşturulacağı tarayıcı seçimini de yapmak mümkün.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Lmgj8Gc_HgMq1UavQaitZw.png"><figcaption>Seçilen testin runner üzerinde koşturulması</figcaption></figure>Bu sayede ortam değişkeni dosyalarından aldığımız bilgilerle senaryo akışına dokunmadan testleri farklı ortamlarda koşacak hâle getirmiş olduk.
Son olarak ufak iki hatırlatma yapayım.
<ul>
<li>Ortam tanımı, Cypress arayüzü ayağa kaldırılmadan evvel yapıldığından ortam değişkenlerinde bir güncelleme yapıldığında test arayüzünün yeniden ayağa kaldırılması gerekmekte. Aksi takdirde değişiklikler senaryolara yansımayacaktır.</li>
<li>Örnek olması açısından ortam dosyalarını <a href="https://github.com/tugsanunlu/cypress-environment-variables">örnek repoya</a> dahil ettim. Fakat gerçek hayat senaryolarında ortam dosyaları içerisinde hassas veriler (API key’ler, kredi kartı bilgileri vs.) tutulacağı için repoya dahil edilmezler. Repoya dahil edilecek .env.example dosyasında yalnızca değişken isimleri tutulur ki testlerin koşturulabilmesi için hangi verilere ihtiyaç duyulduğu anlaşılabilsin.</li>
</ul>
<h4>Sonuç</h4>
Ortamlarla çalışmak, Cypress kullanmanın ilk adımı olarak görülebilir. Uçtan uca testleri yazılabilecek ölçekteki projelerin neredeyse tamamı en azından ikinci bir ortama ihtiyaç duyar. O nedenle Cypress öğrenmeye buradan başlamak bana iyi bir pratik gibi geliyor.
<h4>Kaynaklar</h4>
<ul>
<li><a href="https://docs.cypress.io/guides/guides/environment-variables">https://docs.cypress.io/guides/guides/environment-variables</a></li>
<li><a href="https://github.com/tugsanunlu/cypress-environment-variables">https://github.com/tugsanunlu/cypress-environment-variables</a></li>
</ul>
<blockquote>Cypress serisindeki bir sonraki yazı: <a href="https://tugsanunlu.medium.com/cypress-i%CC%87pu%C3%A7lar%C4%B1-2-iframe-ile-%C3%A7al%C4%B1%C5%9Fmak-6ee08316f40c">Cypress İpuçları #2: Iframe ile Çalışmak</a>
</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=374099ac8603" width="1" height="1" alt="">

recent blog posts