UI Testing and Performance
Frontend Testing
UI da Storybook, Testing Library, Cypress, Mocha, Chai, vb. birçok araç ve kütüphane bulunuyor. Bu kütüphaneler farklı farklı test ve amaçlar için kullanılıyor. Bu yazıda bu amaçların ne olduğunu anlatmaya çalışacağım.
Tahmin edebileceğiniz gibi test konusu oldukça kapsamlı bir konu, pre-prod, prod için farklı amaçlara hizmet eden bir sürü kütüphane bulunuyor. Bu yazıda Frontend için Test türleri şunlar, bunlardır demek yerine, popüler kütüphaneler ve araçlar üzerinden bu test türlerini anlatmayı düşünüyorum.
Not: Bu yazıda daha business odaklı yani yazılım geliştiriciler harici iş akışları ve davranışları test etmenizi sağlayan DSL ile (Given/When/Then) cümleleri ile yazılarak geliştirilen Cucumber, Specflow, Gherkin gibi kütüphaneleri içerMEmektedir
Jasmin, Mocha, Jest, …
Not: TDD ve BDD (Test/Behaviour Driven Development) konularında daha detaylı bilgi almak için önceden yazmış olduğum şu yazıyı okuyabilirsiniz.
JS Node ile birlikte sunucu tarafında kullanılmaya başlayınca, diğer enterprise dillerdeki bir takım test geliştirme araçlarına JS içinde ihtiyaç duyulmaya başlandı. Backend için 2008 yıllarında Jasmine çıktı. Sonrasında Mocha, daha sonrada JS Frontend de yer alan Angular, React, Vue gibi kütüphanelerde kullanılması ile birlikte Facebook Jest Test kütüphanesini çıkardı.
Bu test kütüphaneleri biz geliştiricilerin yazdığı fonksiyon, modül veya sınıfların davranışlarını test etmek ve otomatik CI/CD araçlarına bağlamamızı sağlayan test bloklarıdır. Bir test suit içerisinde test durumlarını yazarak testinizi gerçekleştirsiniz.
Jasmine ile Mocha arasındaki temel fark Jasmine kendi assertion ve mock/spy yapılarını kullanırken, Mocha kütüphanesi assertion ve mock/spy için farklı farklı kütüphaneler ile entegre edilebiliyor olması. Mocha kütüphanesi genelde assertion için Chai, mock/spy için Sinon kütüphanesi kullanılır.
Jest ise daha sonradan UI bileşenlerinde testler geliştirmek için Facebook tarafından geliştirilmiş ve React create-react-app ile oluşturulan projelerde sistemde hazır olarak gelmektedir. Diğer UI kütüphaneleri ile kurulumu da oldukça basit bir şekilde yapılabilmektedir. Jest kütüphanesinde de assertion ve mocking yapısı hazır olarak gelmektedir. Ekstradan UI bileşenlerine snaphsotTest yapabileceği ve bileşenin 2 bellek görüntüsünü karşılaştırabileceğimiz araçlara sahiptir.
JSDOM, React-Test-Renderer, Enzyme, …
UI Bileşenleri ile uğraşırken bunların gerçekleştirim detaylarından çok, bu bileşen ilgili fonksiyonu düzgün gerçekleştirebiliyor mu? Hata durumları için düzgün çıktılar üretebiliyor mu ? Sorularının cevapları önemlidir.
UI yazdığınız testlerin sürekli kırılgan hale gelip, tekrar tekrar testin bakımından kafayı kaldıramamak iyi bir test yaklaşımı değildir.
Burada UI Bileşenlerini fonksiyonel olarak nasıl test edebiliriz dediğimizde. UI kütüphanelerinin tarayıcının algılayacağı DOM ürettiğini ve bu DOM üzerinden Query ederek assertion yapabilmemizi sağlayan tarayıcının DOM yapısını basit anlamda simule edebilecek bir yapıyı ihtiyaç duyulur. Burada en çok kullanılan JSDOM,
- React Test Renderer: 163K (Lightweight Similar to VDOM)
- Enzyme: 19K (Shallow Test for React Components)
- JSDOM:15K star. (Lightweight, Similar to DOM)
React farklı farklı Renderer bulunduğunu react-dom, react-dom/server, react-native, react-test-renderer, react-art. Implementation bu renderer içerisinde gerçekleştiğini anlatılmaktadır.
Cheerio, Enzyme, ….
Not: Cheerio, Web Crawling yaparken ilgili web sayfasını DOM kısmına JQuery benzer basitleştirilmiş bir API üzerinden erişime izin verir. Ama Visual bir Rendering içermediği için UI DOM testlerinde kullanılmaz.
Cheerio is not a web browser
Cheerio parses markup and provides an API for traversing/manipulating the resulting data structure. It does not interpret the result as a web browser does. Specifically, it does not produce a visual rendering, apply CSS, load external resources, or execute JavaScript. If your use case requires any of this functionality, you should consider projects like Puppeteer or JSDom.
UI Teslerinde bileşenler Render edilir. Bu rendering işlemleri Renderer kütüphanelerinde gerçekleşir. Örneğin React konusundaki bir yazımda Dan Abramov şu açıklamasından bahsetmiştim. Burada aslında React gerçekleştirimlerinin aslında Renderer olduğunu görebilirsiniz. Siz Renderer ile VDOM oluşturmak için react-dom, native çıktı oluşturmak için react-native , test için react-test-renderer kullanabilirsiniz.
Storybook, React Cosmo, React Styleguidist, Bit …
Not: Bileşen Odaklı UI Geliştirme konusunda daha detaylı bilgi almak için daha önceden yazmış olduğum şu yazıyı okuyabilirsiniz.
Kurumsal Firmalarda genelde birden fazla proje ve bu projelerde geliştirilen birden fazla UI uygulaması olabilir. Bu durumda farklı farklı ekiplerin belki birbirine benzer bileşenlerin biraz farklılaşarak geliştirilmesi veya kullanması gerekiyor. Aksi halde her ekibin kendi bileşenlerini geliştirmesi hem kod anlamında tekrar, tasarım ve kullanım anlamında farklılık anlamına gelir. Bu durumun oluşmasını şirketler istemez.
Peki şirket içerisinde farklı ekipler birbirleri ile nasıl haberleşecek veya bileşenler konusunda nasıl senkron olacak? Burada hazırlanan bileşenlerin sunulması, paylaşılması ve bileşenlerin ne tarz özellik ve yeteneklerinin olduğunun anlatılması gerekiyor.
UI bileşen yeteneklerini anlatmak için sadece doküman yeterli olmuyor. Bunu görsel olarak sunabildiğiniz component explorer dediğimiz bileşen gezginleri ile bu bileşenleri hemen deneyebilme ve özelliklerini anlayabilme ortamlarına ihtiyaç duyarsınız.
İşte tam bu noktada, şirketlerin Design System üzerine hazırlanmış Design Prensipleri geliştirilmiş Bileşen Kütüphaneleri aşağıda bahsettiğim araçlar ile bu UI Bileşenlerini hem soyutlayabildiklerini, hemde listeleme yapabildiklerini ve özelliklerini test etmek için araçlar sunduğunu görebilirsiniz. (Soyutlamak : Veri katmanından ve Diğer Bileşen Etkileşimlerinden bağımsız hale getirerek, bileşeni göstermek istediğiniz özellikleri yetecek veri ile besleyerek çalıştırmak anlamında)
Selenium, PhantomJS, CasperJS, Puppeteer, Playwright, …
Tarayıcılar üzerinde End-to-End testler koşmak, entegrasyon testleri koşma olayları 2004 yılında Selenium ile başladı. O zamanlar Selenium ile Java kodlayarak UI kullanıcının davranışlarını sisteminize Driver kurarak bu Driver aracılığı ile tarayıcılara iletilerek bu kullanıcı davranışları simüle edilirdi. Arada kullanılan Driver ve Gerçek tarayıcıların çalışması hem performans hemde testlerin her zaman doğru şekilde çalışmamasına neden oluyordu.
UI Testleri sırasında gerçek tarayıcıları ayağa kaldırmadan testleri koşmanın yöntemleri aranmaya başladı. Burda Headless Browsers dediğimiz PhantomJS (Webkit üzerinde çalışan) SlimerJS (Gecko üzerinde çalışan) tarayıcı benzeri araçlar ortaya çıktı. Bu araçlar CLI (command line interface) üzerinden başlatılabiliyorlar, networking ve tarayıcıların tüm davranışlarını yerine getirebiliyorlardı. Bu sayede test otomasyonlarında ve DDOS benzeri testlerde sıklıkla kullanılır oldular. Bu aşamada bunlar üzerinde daha basit komutlar ile scripting ile bu işlemleri daha basit yapabilmelerini sağlayan CasperJS gibi kütüphanelerde çıktı.
Chrome ve Firefox arka arkaya Headless versiyonlarını çıkarıp bunları kendi yapılarında destekliyor olmaları Headless çıkan ilk kütüphanelere (PhantomJS,SlimerJS) ilginin azalmasına neden olmuştur ve bu kütüphaneler geliştirilmesi durdurulmuştur. Headless Chrome ile birlikte Google tarafından browser automation tool için Puppeteer geliştirilmiş bu tool Headless Chrome içerisinde bundled olarak gelmesi, Chrome ile iletişim olarak Chrome Dev Tool Protocol kullanıyor olması performans ve kullanım açısından bir çok kolaylıklar sağlamaktadır. Bu sayede tarayıcı üzerinde manual yaptığınız bir çok şeyi artık Puppeteer ile bir API üzerinden yapabilir hale gelmiş olduk.
https://pptr.dev/ sayfasından
* Sayfaların görüntülerini ve PDF'lerini alabilmek.
* SPA ve SSR sayfaları Crawl edebilme
* UI Testing sırasında gerçekleştiren Keyboard, Input ve Form submission gerçekleştirebilir
* Güncel automated test ortamları oluşturarak bunlar üzerinden JavaScript ve Chrome tarayıcı özelliklerinin en son versiyonları ile kullanabilme imkan
* Performance problemlerinin teşhisinde timeline trace kaydedilmesini
* Chrome Extension test edebilmesini sağlar.
2020 yılında Microsoft tarafından Puppeteer versiyonu Chrome dışında diğer tarayıcılar tarafından desteklenmesi için (firefox, webkit) desteği gelmesi. Mobile Safari ve Geolocation özelliklerini desteklemesi için Playwright kütüphanesi çıkarılmıştır.
Son olarak da Cypress den bahsetmek istiyorum. Cypress yukarıda bahsettiğimiz Puppeteer ve Playwright araçlarından farklı bir yol izleyerek End-to-End testleri geliştirmemizi sağlıyor. Yukarıda bahsettiğim araçlar Protocol ile DevTool erişerek Chrome Headless çalıştırmaya hedeflerken Cypress Chrome Context çalışarak testlerin o context içerisinde diğer JS kütüphanelerinin işletilmesini sağlar.
Cypress içerisinden bir kaç ekran göstererek test için özelleşmiş araçlarından da bahsetmekte fayda var.
- Bir Test dosyasının üzerine basıldığında bunun içerisindeki bütün testleri tek tek koşarak sol tarafta bu komutları koşma adımları ve sonuçlarının gösterildiği Command Log, sağ tarafta da bu test adımları koşarken her bir adımın yaptığını görsel olarak görebilme imkanı bulursunuz.
2. Cypress içerisinde Integration paketi altında yazılan tüm testler listeleyen ve bu testlere hızlı erişmenizi saplayan Spec File Search kısmı, Sağ tarafta da bu testleri hangi ortamda koşturmak istediğinizi seçeceğiniz bir dropdown bileşeni bulunuyor.
3. Koşan Testler ile ilgili sonuçları en son ne zaman koştuğunu ilgili CI sonuçlarını görüntülediğiniz ekrandır
Bu açılardan Cypress diğer araçlara göre daha geliştirme sırasında da kullanılabilecek bir araç gibi düşünülebilir.
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
