Sunucusuz uygulamalarınızı test etmenin en iyi yolları
Sunucusuz bir bulut bilişim yürütme modelinden daha fazlasıdır. Uygulamaları planlama, geliştirme ve uygulama yöntemimizi değiştirir. Ancak uygulamalarımızı test etme yöntemimizi de değiştiriyor.
Alex ile tanış. Alex, son zamanlarda Node.js üzerine odaklanan sıradan bir JavaScript geliştiricisidir.
Son birkaç ay boyunca, iyi arkadaşları Anna ve Jeff, her zaman o sunucusuz şeyden bahsediyorlar. Zaman zaman can sıkıcı olsalar bile, sunucusuz uygulamalar fikrini seviyor. Hatta bir noktada birkaç basit işlevi AWS Lambda ve Azure'a dağıttı.
Bir noktada, Alex ve ekibi yeni bir proje aldı. Bazı analizlerden sonra, Alex, sunucusuz için mükemmel bir seçim olacağını düşündü. Bu fikri ekibine sundu. Takım üyelerinden bazıları heyecanlandı, bir tanesi beğenmedi, ama çoğunun güçlü bir görüşü yoktu. Böylece, denemeye karar verdiler - proje çok büyük değildi ve risk düşüktü.
Ekip sunucusuzca okudu ve yeni uygulamalarını nasıl yapılandıracakları hakkında fikir edindiler. Ancak hiç kimse, ortak geliştirme süreçlerine nasıl sunucusuz uyması gerektiğinden emin değildi.
O anda, süreçleri şöyle gözüküyor:
- Yeni bir özelliği analiz ediyorlar.
- Daha az karmaşık özellikler için kodla başlıyorlar, sonra yerel olarak çalıştırıyorlar ve sonunda bazı testler ekliyorlar.
- Daha karmaşık özellikler için TDD versiyonlarını yaparlar: testlerle başlarlar, sonra kodu yazarlar ve yerel olarak test ederler.
- Özellik hazır olduğunda, test ortamına yerleştiren CI aracına gider.
- Daha sonra KG ekibi, başka bir manuel test turu için yeni bir özellik alır. Her şey iyi görünüyorsa, uygulama üretime CI'den geçer.
Adım adım başlamaya karar verdiler ve sonra sorunları karşılaştıkları gibi çözdüler.
Küçük bir özellik seçtiler ve basit olduğu için kodla başladılar. Kodlama bölümü hazır olduğunda ilk barikatı tıklattılar: sunucusuz uygulamaları yerel olarak nasıl kullanıyorsunuz?
Yerel test
Sunucusuz uygulamalarla, altyapıyı yönetemezsiniz. Kulağa harika geliyor, ancak uygulamanızı yerel olarak nasıl çalıştırırsınız? Bunu bile yapabilir misin?
Uygulamanıza ve sunucusuz satıcıya bağlı olarak, uygulamanızın bazı bölümlerini yerel olarak çalıştırabilirsiniz. Bunu yapmak için, aşağıdaki araç ve tekniklerden bazılarını kullanabilirsiniz:
- Azure İşlevleri Çekirdek Araçları (Azure işlevleri için)
- AWS SAM CLI (AWS SAM kullanılarak oluşturulan AWS Lambda uygulamaları için)
- Üçüncü taraf araçları (örneğin, yerel ayar)
- AWS Lambda yerel simülasyonu için docker-lambda
- Yerel olarak Node.js işlevini çalıştırın
Tabii ki, liste tam değil - daha fazla araç var ve hemen hemen her gün yeni araçlar görüyoruz.
Bu araçların çoğu belirli sınırlamalara sahiptir. Sunucusuz fonksiyonları ve API Ağ Geçidi gibi birkaç servisi daha taklit edebilirler. Ancak izinler, auth katmanı ve diğer hizmetler ne durumda?
Yerel testler, fonksiyonunuzun çalıştığından emin olmak için hızlı doğrulamalar yapmanıza yardımcı olur. Ancak, sunucusuz uygulamanızın amaçlandığı şekilde çalıştığından emin olmanın daha iyi bir yolu var mı? Evet var. İlk ve en önemli adım şudur: yazma testleri.
Böylece Alex ve ekibi ilk işlevlerini yerel olarak denediler ve çalışıyor gibi göründüler. Sonra bir sonraki adıma geçtiler.
Otomatik testler
Alex ve ekibi Node.js uygulamalarını test etmek için Jest’e geçti. Hala çok fazla ön uç yapıyorlar, bu yüzden ellerinden geldiğince tam yığını için aynı araçları kullanmak istiyorlar. Jest'i, sunucusuz uygulamaları test etmek için de kullanabilirler mi? Ve ne test etmeli?
Hızlı bir araştırmadan sonra, en sevdikleri Node.js test araçlarını kullanabileceklerini fark ettiler. Jest, Jasmine, Mocha ve diğerleri serverless ile gayet iyi çalışıyorlar.
Sunucusuz bir uygulamada neler test etmelisiniz?
Node.js uygulamaları ile Alex ve ekibi, üç aşamalı test otomasyon piramidini takip ediyor. Test piramidi ilk olarak Mike Cohn tarafından “Agile ile Başarılı” adlı kitabında yer aldı.
Test piramidinin tanımladığı gibi:
- Birçok birim testi, çünkü bunlar en ucuzlarıdır (en hızlı yazma ve çalıştırma)
- Daha az entegrasyon testi, çünkü daha pahalılar ve çalışması daha uzun sürüyor
- Birkaç UI testi, çünkü bunlar en pahalı olanıdır (bazı GUI aracı gerektirir) ve çalıştırılması en yavaş
Bunların yanı sıra, QA ekibi tarafından yapılan el ile oturuma dayalı testlere de sahipler.
Sunucusuz test otomasyon piramidini nasıl etkiler?
Cevap, seviyeye göre değişir. Ancak test piramidi Mısır piramitlerine daha az benziyor ve Maya piramitlerine benziyor.
Birim test katmanı çok etkilenmez. Ünite testleri hala yazması ve çalıştırması en ucuz olanıdır, ancak üniteler daha küçük olabilir.
Bütünleştirme testleri katmanı her zamankinden daha önemli hale geliyor, çünkü sunucusuz uygulamalar büyük ölçüde entegrasyonlara dayanıyor. Aynı zamanda daha ucuz, çünkü sadece test için sunucusuz bir veritabanına sahip olmak ucuz. Bu nedenle, sunucusuz bir “test piramidinde” daha fazla entegrasyon testine ihtiyacınız var.
GUI testleri katmanı, daha ucuz paralelleştirme nedeniyle daha ucuz ve daha hızlıdır.
Manuel test katmanı aynı kalır. Ancak sunucusuz biraz geliştirmenize yardımcı olabilir. Bununla ilgili ayrıntılara gireceğiz.
Alex ve ekibi nihayet nereye odaklanacakları konusunda bir fikir edindi. Bir sonraki sorun, onları daha kolay test etmek için nasıl bir fonksiyon yazılacağıydı.
Test edilebilir bir sunucusuz fonksiyonlar nasıl yazılır
Sunucusuz bir işlev yazarken aşağıdaki riskleri düşünmeniz gerekir:
- Yapılandırma riskleri Veri tabanı ve tablo doğru mu? Veya erişim haklarınız var mı?
- Teknik iş akışı riskleri Gelen isteği isteğiniz gibi ayrıştırıyor ve kullanıyor musunuz? Veya, başarılı yanıtları ve hataları doğru mu yapıyorsunuz?
- İş mantığı riskleri Uygulamanızın sahip olduğu tüm iş mantığı kurallarını takip ettiniz mi?
- Entegrasyon riskleri Gelen istek yapısını doğru okuyor musunuz? Yoksa emri doğru bir şekilde veritabanına mı saklıyorsunuz?
Sunucusuz işlevinin doğru çalıştığını onaylamak için tüm bu riskleri test etmeniz gerekir.
Bunların her birini entegrasyon testleri için yaptığınız gibi test edebilirsiniz. Ancak, bu risklerden biri için test etmek istediğiniz her seferinde hizmeti ayarlamak ve yapılandırmak uygun değildir. Arkadaşım Aleksandar Simovic'in dediği gibi:
Otomobilleri test etmenin bu şekilde yapılıp yapılmadığını düşünün. Bu, bir arabadaki tek bir vidayı veya hatta bir aynayı test etmek istediğinizde, tüm aracı bir araya getirip sökmeniz gerektiği anlamına gelir.
Uygulamayı daha test edilebilir hale getirmek için açık çözüm, işlevinizi daha küçük olanlara bölmektir.
Bunu yapmanın en iyi yollarından biri, Hexagonal Architecture'ı sunucusuz işlevlerinize uygulamaktır.
Altıgen Mimari veya Limanlar ve Adaptörler, endişelerin sorumluluk katmanları yoluyla ayrılmasını destekleyen bir uygulama mimarisi şeklidir. Yaratıcısı Alistair Cockburn şöyle açıklıyor:
Bir uygulamanın kullanıcılar, programlar, otomatik test veya toplu komut dosyaları tarafından eşit bir şekilde sürülmesine ve nihai çalışma zamanı cihazları ve veritabanlarından ayrı olarak geliştirilmelerine ve test edilmelerine izin verin.
Peki, bu sunucusuz fonksiyonlara nasıl uygulanır?
Alex ve ekibi AWS'yi kullandıkça, aşağıdaki gibi bir yapıya sahip oldular:
- İşlevsel iş mantığı birkaç “port” sergiler (veya birkaç argüman bekler). Örneğin, biri gelen etkinlik için, biri kalıcı depolama için, diğeri bildirimler için.
- Bir işlevi tetikleyen olay için iki adaptör, bir tanesi gerçek AWS Lambda tetikleyicisi için diğeri de yerel test için.
- Kalıcı depolama ve bildirimler için çeşitli adaptörleri vardır. Örneğin, DynamoDB masa adaptörü ve hafıza içi adaptör.
Alex ve ekibi, ileriye gittikleri için mutluydu. Ancak, devam etmeden önce, Hexagonal Architecture'ın test piramidinin her aşamasını nasıl etkilediğini görelim.
Birim testi
Birim testleri aynı kaldı. Ancak, Altıgen Mimari nedeniyle birim testleri yazmak daha kolaydır. Fonksiyon iş katmanını ayrı ayrı test etmek için basitçe yerel bir adaptör kullanabilir veya bir adaptör olarak alay edebilirler.
Entegrasyon testi
Entegrasyon testleri Hexagonal Architecture'dan çok yararlandı. Sahip oldukları entegrasyonları tamamen test edebildiler. Üçüncü taraf entegrasyonları diğer adaptörler ile simüle edilmiştir.
Bu pratikte nasıl çalışır?
Sunucusuz işlevlerinin her biri lambda.js ve main.js dosyalarına sahiptir. Ana dosya, sunucusuz bir işlevin iş mantığını içerir. Lambda.js dosyası da bağdaştırıcıları kablolamaktan ve ana.js dosyasını çağırmaktan sorumludur.
Ana dosyanın kendi birimi ve entegrasyon testleri vardır. Ancak entegrasyon testleri, AWS S3 gibi son servislerle tam entegrasyon testi yapmıyor, çünkü bu onları yavaşlatıyor. Bunun yerine, işlevi dosya depolama entegrasyonuyla sınamak için bellek içi bir adaptör kullanırlar.
AWS S3 entegrasyonu, kendi birimi ve entegrasyon testlerini içeren FileRepository ile yapılır. Entegrasyon test kontrolleri, son entegrasyonun gerçekten çalıştığından emin olmak için AWS S3'ü kullanır.
Main.js'nin tersine, lambda.js dosyasının sınaması yoktur, çünkü çoğu zaman yalnızca birkaç satırlık bir kod satırı vardır.
Bu yaklaşım, MindMup ekibinin sunucusuz fonksiyonları test etmek için kullandığı teknik gibidir. Bununla beraber, fonksiyonlarınızın entegrasyonlarını kolayca test edebilirsiniz ve yine de entegrasyon testlerinizi daha hızlı yapabilirsiniz.
GUI testi
Alex ve ekibi uygulamanın arka ucunu oluştururken, GUI testleri aşaması önemli değildi. Ancak sunucusuz hakkında daha fazla şey öğrendiklerinde, üzerinde çalıştıkları diğer uygulamalar için GUI testlerini geliştirmek için kullanabileceklerini fark ettiler.
UI testleri pahalı ve yavaştır, çünkü tarayıcıda çalışırlar. Ancak, sunucusuz ucuzdur ve hızlı ölçeklenir.
AWS Lambda'da bir tarayıcı çalıştırabilirlerse, ucuz paralellik kazanacaklardı. Bu UI testlerini daha ucuz ve daha hızlı yapar.
Ancak, sunucusuz bir işlevin içinde Chrome gibi bir tarayıcı çalıştırabilir misiniz?
Evet! Ayrıca, Serverless Chrome, Chromeless ve Puppeteer gibi araçlar sayesinde kolaydır.
Sunucusuz ve kafasız tarayıcıların bir kombinasyonu bize yeni nesil UI test araçları getirebilir. Appraise gibi bazılarını görüp deneyebiliriz.
CI / CD
Alex ve ekibi ilk sunucusuz işlevlerini test ettikçe, kodu test ortamına dağıtmanın zamanı gelmişti. Bu yeni bir soruyu gündeme getirdi: CI / CD araçlarını sunucusuz uygulamalarını dağıtmak için nasıl kullanabilirler?
Cevap basit: Testleri çalıştırmak ve uygulamayı dağıtmak için bir CI aracı kullanabilirler. Uygulamayı dağıtmak için, Claudia.js, AWS SAM ve Serverless Framework gibi herhangi bir popüler aracı kullanın.
En sevdiğiniz CI aracını hala kullanabilirsiniz (Jenkins, TravisCI veya SemaphoreCI gibi) veya AWS'ye bağlı kalmak istiyorsanız AWS CodeBuild'i deneyebilirsiniz.
Manuel test
Manuel testler yoluyla bile sunucusuz doğrudan etkilenmiyor olsa da, ekip kendi QA sürecini iyileştirmenin bir yolunu buldu.
Sunucusuz uygulamanın aşamaları ve konuşlandırması ucuz ve kurulumu çok hızlı. Ayrıca, sunucusuz olan hiç kimse kullanmıyorsa uygulamanın ücretini ödemezsiniz.
Bu, test ortamına sahip olmanın hiç bu kadar ucuz olmamıştı!
Ayrıca, sunucusuz olarak, işlevi bir aşamadan diğerine sık sık tanıtabilirsiniz. Bu, QA ekibinizin bir işlevi test edebileceği ve çalıştığını onayladığında, aynı işlevi üretime teşvik edebileceğiniz anlamına gelir.
Testin ötesinde
Alex ve ekibi, ilk sunucusuz işlevlerini ön üretime gönderdiler ve ekip, sunucusuz uygulamaları test etmeyi öğrendikleri için mutluydu.
Projede sunucusuz kullanmaya devam ettiler ve onu birkaç başka projeyle tanıştırdılar. Alex, arkadaşları olan Anna ve Jeff'e, bazen sinir bozucu, sunucusuz bir vaiz olarak katıldı. Ve sonsuza kadar mutlu yaşadılar.
Sonrası komut
Ancak uygulamaları iyi bir şekilde test edilmesine rağmen, gece boyunca bir şeyler oldu.
Bir soruşturmadan sonra, entegrasyonlardan birinin değiştiğini öğrendiler. Sunumun sunucusuz uygulamalar için önemli olduğunu öğrendiler, ancak yeterli değil.
Sunucusuz uygulamalar büyük ölçüde entegrasyonlara bağlı olduğundan, risk kodunuzdan entegrasyonlara geçiş yapar. Entegrasyon değişikliklerini yakalayabilmek ve hızlı tepki verebilmek için uygulamanızın doğru bir şekilde izlenmesi gerekiyor.
Neyse ki, piyasada her geçen gün daha fazla sunucusuz izleme aracı bulunmaktadır. İyi ve popüler seçeneklerden bazıları IOpipe, Thundra, Dashbird ve Epsagon.
Ancak, sunucusuz uygulamalar genellikle kalın bir istemciye sahiptir, bu da arka uç izlemenin yeterli olmadığı anlamına gelir. Ön uç için benzer bir araca ihtiyacınız var. Bu pazarda Sentry ve Rollbar gibi birçok güzel araç var.
Ancak sunucusuz ruhu altında Desole adlı açık kaynaklı bir hata izleme uygulaması oluşturduk. AWS hesabınıza kurabileceğiniz sunucusuz bir uygulamadır. Kuruluşların, bir hizmet olarak yazılımın rahatlığı ile kendi kendine barındırılan bir çözümün güvenliği arasında seçim yapmak zorunda kalmadan uygulama istisnalarını ve hatalarını izlemelerini sağlar. Burada kontrol edebilirsiniz: https://desole.io.
Tüm resimler SimpleDiagrams4 uygulaması kullanılarak oluşturulur.
Node.js ve AWS kullanarak sunucusuz uygulamaları test etme ve oluşturma hakkında daha fazla bilgi edinmek istiyorsanız, Yayınları Yönetmek için Aleksandar Simovic ile yazdığım kitap olan “Node.js ile Sunucusuz Uygulamalar” bölümüne bakın:
Kitap size kodsuz örneklerle sunucusuz testler hakkında daha fazla bilgi verecek, fakat ayrıca Node ve Claudia.js kullanarak gerçek bir dünya sunucusuz API (DB ve kimlik doğrulama ile) oluşturmayı ve hata ayıklamayı da öğreneceksiniz. Facebook Messenger ve SMS (Twilio kullanarak) ve Alexa becerileri için nasıl sohbetler oluşturulacağını öğreneceksiniz.