Cara menguji fungsi dan aplikasi tanpa server

Menguji fungsi tanpa server menggunakan jenis dan teknik pengujian tradisional, tetapi Anda juga harus mempertimbangkan pengujian aplikasi tanpa server secara keseluruhan. Cloud-based pengujian memberikan ukuran kualitas yang paling akurat dari fungsi Anda dan aplikasi tanpa server.

Arsitektur aplikasi tanpa server mencakup layanan terkelola yang menyediakan fungsionalitas aplikasi penting melalui panggilan API. Untuk alasan ini, siklus pengembangan Anda harus mencakup pengujian otomatis yang memverifikasi fungsionalitas ketika fungsi dan layanan Anda berinteraksi.

Jika Anda tidak membuat pengujian berbasis cloud, Anda dapat mengalami masalah karena perbedaan antara lingkungan lokal dan lingkungan yang digunakan. Proses integrasi berkelanjutan Anda harus menjalankan pengujian terhadap rangkaian sumber daya yang disediakan di cloud sebelum mempromosikan kode Anda ke lingkungan penerapan berikutnya, seperti QA, Staging, atau Produksi.

Lanjutkan membaca panduan singkat ini untuk mempelajari tentang strategi pengujian untuk aplikasi tanpa server, atau kunjungi repositori Sampel Pengujian Tanpa Server untuk mempelajari contoh-contoh praktis, khusus untuk bahasa dan runtime pilihan Anda.

Untuk pengujian tanpa server, Anda masih menulis unit, integrasi, dan pengujian ujung ke ujung.

• Tes unit - Pengujian yang berjalan terhadap blok kode yang terisolasi. Misalnya, memverifikasi logika bisnis untuk menghitung biaya pengiriman yang diberikan item dan tujuan tertentu.

• Tes integrasi - Pengujian yang melibatkan dua atau lebih komponen atau layanan yang berinteraksi, biasanya di lingkungan cloud. Misalnya, memverifikasi fungsi memproses peristiwa dari antrian.

• End-to-end pengujian - Pengujian yang memverifikasi perilaku di seluruh aplikasi. Misalnya, memastikan infrastruktur diatur dengan benar dan bahwa peristiwa mengalir antar layanan seperti yang diharapkan untuk mencatat pesanan pelanggan.

Hasil bisnis yang ditargetkan

Menguji solusi tanpa server mungkin membutuhkan lebih banyak waktu untuk disiapkan. Anda harus memverifikasi interaksi berbasis peristiwa antar layanan. Ingatlah alasan bisnis praktis ini saat Anda membaca panduan ini:

• Tingkatkan kualitas aplikasi Anda

• Kurangi waktu untuk membangun fitur dan memperbaiki bug

Kualitas aplikasi tergantung pada pengujian banyak skenario. Pertimbangkan skenario bisnis Anda dan otomatiskan pengujian untuk dijalankan terhadap layanan cloud. Ini meningkatkan kualitas aplikasi Anda.

Bug dan masalah konfigurasi harganya lebih murah ketika tertangkap di awal siklus pengembangan. Masalah yang tidak terdeteksi sampai produksi membutuhkan lebih banyak upaya dan lebih banyak orang untuk memperbaikinya.

Strategi pengujian tanpa server yang baik meningkatkan kualitas perangkat lunak dan mempercepat iterasi. Ini memverifikasi bahwa fungsi dan aplikasi Lambda Anda bekerja seperti yang diharapkan di cloud.

Apa yang harus diuji

Kami merekomendasikan strategi pengujian yang menguji perilaku layanan terkelola, konfigurasi cloud, kebijakan keamanan, dan integrasi dengan kode Anda. Pengujian perilaku, juga dikenal sebagai pengujian kotak hitam, memverifikasi bahwa sistem bekerja seperti yang diharapkan tanpa mengetahui bagian dalamnya.

• Jalankan pengujian unit untuk memeriksa logika bisnis di dalam fungsi Lambda.

• Verifikasi layanan terintegrasi benar-benar dipanggil, dan parameter input benar.

• Periksa apakah suatu peristiwa melewati semua layanan yang diharapkan dari ujung ke ujung dalam alur kerja.

Dalam arsitektur berbasis server tradisional, tim sering menguji hanya kode yang berjalan di server aplikasi. Mereka menganggap komponen, layanan, atau dependensi lain sebagai eksternal dan di luar ruang lingkup.

Aplikasi tanpa server terdiri dari unit kerja kecil. Contohnya termasuk fungsi Lambda yang mengambil produk dari database, memproses item dari antrian, atau mengubah ukuran gambar dalam penyimpanan. Setiap komponen berjalan di lingkungannya sendiri. Tim mengelola banyak unit kecil ini dalam satu aplikasi.

Beberapa fungsi dapat ditangani sepenuhnya oleh layanan terkelola seperti Amazon S3, atau dibangun tanpa kode khusus. Anda tidak perlu menguji layanan terkelola ini. Namun, Anda harus menguji bagaimana kode Anda terintegrasi dengan mereka.

Cara menguji serverless

Anda mungkin tahu cara menguji aplikasi yang digunakan secara lokal. Anda menulis tes terhadap kode di desktop Anda atau di dalam wadah. Misalnya, Anda dapat memanggil layanan web lokal dan kemudian memeriksa responsnya.

Solusi tanpa server menggunakan kode fungsi dan layanan terkelola berbasis cloud, seperti antrian, database, bus acara, dan sistem pesan. Komponen-komponen ini terhubung melalui arsitektur berbasis peristiwa, di mana pesan, yang disebut peristiwa, mengalir dari satu sumber daya ke sumber daya lainnya. Beberapa interaksi sinkron, seperti layanan web yang mengembalikan hasil segera.

Lainnya asinkron, seperti menempatkan item dalam antrian atau memulai langkah alur kerja. Strategi pengujian Anda harus mencakup kedua jenis dan menguji interaksi antar layanan. Untuk interaksi asinkron, Anda mungkin perlu mendeteksi efek samping di komponen hilir yang tidak segera terlihat.

Anda tidak dapat sepenuhnya mereplikasi lingkungan cloud secara lokal. Ini termasuk antrian, tabel database, bus acara, dan kebijakan keamanan. Perbedaan antara lingkungan lokal dan cloud menyebabkan masalah. Perbedaan ini meningkatkan waktu untuk mereproduksi dan memperbaiki bug.

Dalam aplikasi tanpa server, komponen ada sepenuhnya di cloud. Pengujian terhadap kode dan layanan cloud diperlukan untuk mengembangkan fitur dan memperbaiki bug.

Teknik pengujian

Strategi pengujian Anda mungkin mencakup campuran teknik. Anda menggunakan tes interaktif cepat untuk men-debug fungsi di konsol. Anda menulis pengujian unit otomatis untuk memeriksa logika bisnis. Anda memverifikasi panggilan ke layanan eksternal dengan tiruan. Anda juga dapat menguji terhadap emulator yang meniru layanan.

• Pengujian di cloud: Anda menerapkan infrastruktur dan kode untuk menguji dengan layanan aktual, kebijakan keamanan, dan konfigurasi. Cloud-based tes memberikan ukuran paling akurat dari kualitas kode Anda.

  Men-debug fungsi di konsol adalah cara cepat untuk menguji di cloud. Anda dapat memilih dari contoh acara pengujian atau membuat acara khusus. Anda juga dapat berbagi acara pengujian dengan tim Anda melalui konsol.

  Untuk mengotomatiskan pengujian dalam siklus pengembangan dan pembuatan, uji di luar konsol. Lihat bagian pengujian khusus bahasa dalam panduan ini untuk strategi otomatisasi.

• Menguji dengan tiruan: Mock adalah objek dalam kode Anda yang mensimulasikan layanan eksternal. Mereka menyediakan perilaku yang telah ditentukan sebelumnya untuk memverifikasi panggilan layanan dan parameter. Pal su adalah tiruan yang mengambil jalan pintas untuk menyederhanakan atau mempercepat pengujian. Misalnya, objek akses data palsu mungkin mengembalikan data dari penyimpanan data dalam memori. Mock dapat menyederhanakan dependensi yang kompleks, tetapi mungkin menyebabkan lebih banyak tiruan untuk menggantikan dependensi bersarang.

• Menguji secara lokal menggunakan AWS SAM CLI: Gunakan AWS SAM CLI untuk memanggil fungsi Lambda secara lokal di wadah Docker yang menggunakan lingkungan runtime yang sama dengan Lambda. AWS Anda dapat menguji logika fungsi dan pemrosesan peristiwa tanpa menerapkan ke cloud.

• Pengujian dengan emulasi: Gunakan LocalStack integrasi dalam VS Code untuk meniru beberapa AWS layanan secara lokal untuk menguji integrasi layanan.

Pengujian di cloud

Pengujian di cloud sangat berharga untuk semua fase pengujian: pengujian unit, pengujian integrasi, dan pengujian ujung ke ujung. Pengujian yang dijalankan terhadap kode dan layanan berbasis cloud memberikan ukuran kualitas kode yang paling akurat.

Cara sederhana untuk menjalankan fungsi Lambda di cloud adalah dengan acara uji di Konsol Manajemen AWS. A cara pengujian adalah input JSON ke fungsi Anda. Jika fungsi Anda tidak memerlukan input, acara dapat berupa dokumen JSON kosong({}). Konsol menyediakan acara sampel untuk banyak integrasi layanan. Anda dapat berbagi acara dengan tim Anda untuk mempermudah pengujian.

Pelajari cara men-debug fungsi sampel di konsol.

catatan

Meskipun menjalankan fungsi di konsol adalah cara cepat untuk men-debug, men gotomatiskan siklus pengujian Anda sangat penting untuk meningkatkan kualitas aplikasi dan kecepatan pengembangan.

Sampel otomatisasi pengujian tersedia di repositori https://github.com/aws-samples/serverless-test-samples Sampel Uji Tanpa Server. Baris perintah berikut menjalankan contoh uji integrasi Python otomatis:

python -m pytest -s tests/integration -v

Meskipun pengujian berjalan secara lokal, ia berbicara dengan sumber daya berbasis cloud. Sumber daya ini dikerahkan menggunakan alat AWS SAM baris perintah AWS Serverless Application Model dan. Kode pengujian pertama-tama mengambil output tumpukan yang digunakan, seperti titik akhir API, fungsi ARN, dan peran keamanan.

Kemudian, ia mengirim permintaan ke titik akhir API. Tanggapan berisi daftar bucket Amazon S3. Pengujian ini berjalan terhadap sumber daya berbasis cloud untuk memverifikasi bahwa sumber daya tersebut digunakan, diamankan, dan berfungsi.

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

Untuk pengembangan aplikasi cloud-native, pengujian di cloud memberikan manfaat berikut:

• Anda dapat menguji setiap layanan yang tersedia.

• Anda selalu menggunakan API layanan terbaru dan mengembalikan nilai.

• Lingkungan pengujian cloud sangat mirip dengan lingkungan produksi Anda.

• Pengujian dapat mencakup kebijakan keamanan, kuota layanan, konfigurasi, dan parameter spesifik infrastruktur.

• Setiap pengembang dapat dengan cepat membuat satu atau lebih lingkungan pengujian di cloud.

• Pengujian cloud meningkatkan kepercayaan kode Anda berjalan dengan benar dalam produksi.

Pengujian di cloud memang memiliki beberapa kelemahan. Penyebaran cloud biasanya membutuhkan waktu lebih lama daripada penerapan desktop lokal.

Alat seperti AWS Serverless Application Model (AWS SAM) Accelerate, mode ton AWS tonan Cloud Development Kit (AWS CDK), dan SST (pihak ke-3) mengurangi latensi ini. Alat ini memantau infrastruktur dan kode Anda, lalu menerapkan pembaruan ke lingkungan cloud Anda secara otomatis.

catatan

Lihat cara membuat infrastruktur sebagai kode di Panduan Pengembang Tanpa Server untuk mempelajari selengkapnya tentang AWS Serverless Application Model, CloudFormation, dan AWS Cloud Development Kit (AWS CDK).

Tidak seperti pengujian lokal, pengujian cloud menggunakan sumber daya yang mungkin menimbulkan biaya. Lingkungan pengujian yang terisolasi dapat menambah pekerjaan untuk DevOps tim Anda, terutama di organisasi dengan kontrol akun yang ketat. Meski begitu, waktu pengembang untuk menyiapkan lingkungan lokal yang kompleks dapat menghabiskan lebih banyak biaya daripada menggunakan lingkungan cloud sekali pakai yang dibangun dengan Infrastructure as Code tools.

Pengujian di cloud, bahkan dengan pertimbangan ini, masih merupakan cara terbaik untuk menjamin kualitas solusi tanpa server Anda.

Menguji dengan tiruan

Pengujian dengan tiruan adalah teknik di mana Anda membuat objek pengganti dalam kode Anda untuk mensimulasikan perilaku layanan cloud.

Misalnya, Anda dapat menulis tes yang menggunakan tiruan layanan Amazon S3. Mock mengembalikan respons set setiap kali CreateObject metode dipanggil. Itu tidak memanggil Amazon S3 atau titik akhir layanan lainnya.

Kerangka kerja tiruan sering menghasilkan objek tiruan untuk Anda. Beberapa kerangka kerja bersifat generik. Lainnya menar AWS getkan SDK, seperti Moto, perpustakaan Python untuk layanan mengejek. AWS

Objek tiruan berbeda dari emulator. Pengembang membuat tiruan sebagai bagian dari kode pengujian. Emulator adalah aplikasi mandiri yang mengekspos fungsionalitas yang sama dengan sistem yang mereka tiru.

Keuntungan menggunakan tiruan antara lain sebagai berikut:

• Mocks dapat mensimulasikan layanan pihak ketiga yang berada di luar kendali aplikasi Anda, seperti API dan penyedia perangkat lunak sebagai layanan (SaaS), tanpa memerlukan akses langsung ke layanan tersebut.

• Mock berguna untuk menguji kondisi kegagalan, terutama ketika kondisi seperti itu sulit untuk disimulasikan, seperti pemadaman layanan.

• Mock dapat memberikan pengujian lokal yang cepat setelah dikonfigurasi.

• Mock dapat memberikan perilaku pengganti untuk hampir semua jenis objek, sehingga strategi mengejek dapat menciptakan cakupan untuk berbagai layanan yang lebih luas daripada emulator.

• Ketika fitur atau perilaku baru tersedia, pengujian tiruan dapat bereaksi lebih cepat. Dengan menggunakan kerangka tiruan generik, Anda dapat mensimulasikan fitur-fitur baru segera setelah AWS SDK yang diperbarui tersedia.

Pengujian tiruan memiliki kelemahan ini:

• Mock umumnya memerlukan sejumlah upaya pengaturan dan konfigurasi yang tidak sepele, khususnya ketika mencoba menentukan nilai pengembalian dari layanan yang berbeda untuk meniru respons dengan benar.

• Mock ditulis, dikonfigurasi, dan harus dipelihara oleh pengembang, meningkatkan tanggung jawab mereka.

• Anda mungkin perlu memiliki akses ke cloud untuk memahami API dan mengembalikan nilai layanan.

• Mock bisa sulit dipelihara. Saat tanda tangan API cloud yang diejek berubah, atau skema nilai pengembalian berkembang, Anda perlu memperbarui tiruan Anda. Mock juga memerlukan pembaruan jika Anda memperluas logika aplikasi Anda untuk melakukan panggilan ke API baru.

• Pengujian yang menggunakan tiruan mungkin lulus di lingkungan desktop tetapi gagal di cloud. Hasil mungkin tidak cocok dengan API saat ini. Konfigurasi layanan dan kuota tidak dapat diuji.

• Kerangka kerja tiruan terbatas dalam menguji atau mendeteksi kebijakan AWS Identitas dan Manajemen Akses (IAM) atau batasan kuota. Meskipun tiruan lebih baik dalam mensimulasikan ketika otorisasi gagal atau kuota terlampaui, pengujian tidak dapat menentukan hasil mana yang sebenarnya terjadi di lingkungan produksi.

Menguji secara lokal menggunakan AWS SAM CLI

Gunakan AWS SAMCLI untuk menguji fungsi Anda di wadah Docker menggunakan lingkungan runtime yang sama seperti AWS Lambda. Anda dapat menguji logika fungsi dan pemrosesan peristiwa secara lokal tanpa menerapkan ke cloud. Jika fungsi Anda membuat panggilan API ke yang lain Layanan AWS, panggilan tersebut mencapai AWS sumber daya nyata.

Keuntungan pengujian dengan wadah lokal meliputi yang berikut:

• Menggunakan lingkungan AWS Lambda runtime untuk pengujian yang akurat.

• Memungkinkan iterasi pengembangan lokal yang cepat tanpa penerapan cloud.

• Mendukung debugging dengan alat pengembangan lokal yang sudah dikenal.

Pengujian dengan wadah lokal memiliki keterbatasan berikut:

• Layanan AWS panggilan dari fungsi Anda berinteraksi dengan AWS sumber daya nyata, yang mungkin menimbulkan biaya dan memengaruhi data produksi.

• Membutuhkan Docker untuk diinstal dan berjalan secara lokal.

Pengujian dengan emulasi

Emulator adalah aplikasi yang berjalan secara lokal yang meniru AWS layanan dengan menyediakan API serupa dan nilai pengembalian. LocalStack adalah alat emulasi populer yang menyediakan lingkungan pengembangan lokal lengkap untuk pengujian integrasi layanan.

LocalStack adalah emulator AWS Cloud yang dapat Anda gunakan untuk menguji aplikasi tanpa server secara lokal. Anda dapat menguji fungsi Lambda yang terintegrasi dengan layanan seperti DynamoDB, Amazon S3, dan Amazon SQS tanpa terhubung ke layanan aktual. AWS Anda dapat menggunakan LocalStack di AWS Toolkit untuk VS Code.

Keuntungan dari tes dengan emulator meliputi yang berikut:

• Emulator dapat membantu iterasi dan pengujian pengembangan lokal yang cepat.

• Emulator menyediakan lingkungan yang akrab bagi pengembang yang terbiasa mengembangkan kode di lingkungan lokal. Misalnya, jika Anda terbiasa dengan pengembangan aplikasi tingkat n, Anda mungkin memiliki mesin database dan server web, mirip dengan yang berjalan dalam produksi, berjalan di mesin lokal Anda untuk menyediakan kemampuan pengujian yang cepat, lokal, dan terisolasi.

• Emulator tidak memerlukan perubahan apa pun pada infrastruktur cloud (seperti akun cloud pengembang), sehingga mudah diterapkan dengan pola pengujian yang ada.

• Karena emulator tidak menggunakan AWS sumber daya aktual, Anda tidak akan mendapatkan biaya tak terduga saat memulai beberapa layanan atau membiarkan beberapa sumber daya berjalan untuk jangka waktu yang lama.

Pengujian dengan emulator memiliki kelemahan berikut:

• Emulator bisa sulit diatur dan ditiru, terutama bila digunakan dalam CI/CD pipeline. Hal ini dapat meningkatkan beban kerja staf TI atau pengembang yang mengelola perangkat lunak mereka sendiri.

• Fitur dan API yang diemulasi biasanya tertinggal dari pembaruan layanan. Hal ini dapat menyebabkan kesalahan karena kode yang diuji tidak cocok dengan API yang sebenarnya, dan menghambat adopsi fitur baru.

• Emulator memerlukan dukungan, pembaruan, perbaikan bug, dan peningkatan paritas fitur. Ini adalah tanggung jawab penulis emulator, yang bisa menjadi perusahaan pihak ketiga.

• Pengujian yang bergantung pada emulator mungkin memberikan hasil yang berhasil secara lokal, tetapi gagal di cloud karena kebijakan keamanan produksi, konfigurasi antar-layanan, atau melebihi kuota Lambda.

Praktik terbaik

Bagian berikut memberikan rekomendasi untuk pengujian aplikasi tanpa server yang berhasil.

Anda dapat menemukan contoh praktis pengujian dan otomatisasi pengujian di repositori Sampel Tes Tanpa Server.

Prioritaskan pengujian di cloud

Pengujian di cloud memberikan cakupan pengujian yang paling andal, akurat, dan lengkap. Melakukan pengujian dalam konteks cloud secara komprehensif menguji tidak hanya logika bisnis tetapi juga kebijakan keamanan, konfigurasi layanan, kuota, dan tanda tangan API terbaru dan nilai pengembalian.

Struktur kode Anda untuk dapat diuji

Sederhanakan pengujian dan fungsi Lambda Anda dengan memisahkan Lambda-specific kode dari logika bisnis inti Anda.

Handler fungsi Lambda Anda harus berupa adaptor ramping yang mengambil data peristiwa dan hanya meneruskan detail yang penting ke metode logika bisnis Anda. Dengan strategi ini, Anda dapat menyelesaikan tes komprehensif di sekitar logika bisnis Anda tanpa khawatir tentang Lambda-specific detailnya. Fungsi AWS Lambda Anda seharusnya tidak memerlukan pengaturan lingkungan yang kompleks atau sejumlah besar dependensi untuk membuat dan menginisialisasi komponen yang sedang diuji.

Secara umum, Anda harus menulis handler yang mengekstrak dan memvalidasi data dari objek peristiwa dan konteks yang masuk, kemudian mengirimkan input itu ke metode yang melakukan logika bisnis Anda.

Mempercepat loop umpan balik pengembangan

Ada alat dan teknik untuk mempercepat loop umpan balik pengembangan. Misalnya, AWS SAM Accelerate dan mode AWS tontonan CDK keduanya mengurangi waktu yang diperlukan untuk memperbarui lingkungan cloud.

Sampel di repositori GitHub Sampel Uji Tanpa Server mengeksplorasi beberapa teknik ini.

Kami juga menyarankan Anda membuat dan menguji sumber daya cloud sedini mungkin selama pengembangan—tidak hanya setelah check-in ke kontrol sumber. Praktik ini memungkinkan eksplorasi dan eksperimen yang lebih cepat saat mengembangkan solusi. Selain itu, mengotomatiskan penerapan dari mesin pengembangan membantu Anda menemukan masalah konfigurasi cloud lebih cepat dan mengurangi upaya yang terbuang untuk pembaruan dan proses peninjauan kode.

Fokus pada tes integrasi

Saat membangun aplikasi dengan Lambda, menguji komponen bersama adalah praktik terbaik.

Pengujian yang berjalan terhadap dua atau lebih komponen arsitektur disebut pengujian integrasi. Tujuan pengujian integrasi adalah untuk memahami tidak hanya bagaimana kode Anda dieksekusi di seluruh komponen, tetapi bagaimana lingkungan yang menghosting kode Anda berperilaku. End-to-end pengujian adalah jenis tes integrasi khusus yang memverifikasi perilaku di seluruh aplikasi.

Untuk membangun pengujian integrasi, gunakan aplikasi Anda ke lingkungan cloud. Ini dapat dilakukan dari lingkungan lokal atau melalui CI/CD pipa. Kemudian, tulis tes untuk melatih sistem yang diuji (SUT) dan memvalidasi perilaku yang diharapkan.

Misalnya, sistem yang diuji dapat berupa aplikasi yang menggunakan API Gateway, Lambda dan DynamoDB. Pengujian dapat membuat panggilan HTTP sintetis ke titik akhir API Gateway dan memvalidasi bahwa respons menyertakan muatan yang diharapkan. Tes ini memvalidasi bahwa kode AWS Lambda benar, dan bahwa setiap layanan dikonfigurasi dengan benar untuk menangani permintaan, termasuk izin IAM di antara mereka. Selanjutnya, Anda dapat merancang pengujian untuk menulis catatan dengan berbagai ukuran untuk memverifikasi kuota layanan Anda, seperti ukuran rekaman maksimum di DynamoDB, diatur dengan benar.

Buat lingkungan pengujian yang terisolasi

Pengujian di cloud biasanya membutuhkan lingkungan pengembang yang terisolasi, sehingga pengujian, data, dan peristiwa tidak tumpang tindih.

Salah satu pendekatannya adalah menyediakan setiap pengembang AWS akun khusus. Ini menghindari konflik dengan penamaan sumber daya yang dapat terjadi ketika beberapa pengembang bekerja di basis kode bersama, mencoba menerapkan sumber daya atau memanggil API.

Proses pengujian otomatis harus membuat sumber daya dengan nama unik untuk setiap tumpukan. Misalnya, Anda dapat mengatur skrip atau file konfigurasi TOML sehingga perintah AWS SAM CLI sam deploy atau sam sync secara otomatis menentukan tumpukan dengan awalan unik.

Dalam beberapa kasus, pengembang berbagi AWS akun. Ini mungkin karena memiliki sumber daya di tumpukan Anda yang mahal untuk dioperasikan, atau untuk penyediaan dan dikonfigurasi. Misalnya, database mungkin dibagikan untuk membuatnya lebih mudah untuk mengatur dan menyemai data dengan benar

Jika pengembang berbagi akun, Anda harus menetapkan batasan untuk mengidentifikasi kepemilikan dan menghilangkan tumpang tindih. Salah satu cara untuk melakukannya adalah dengan mengawali nama tumpukan dengan ID pengguna pengembang. Pendekatan populer lainnya adalah mengatur tumpukan berdasarkan cabang kode. Dengan batas cabang, lingkungan terisolasi, tetapi pengembang masih dapat berbagi sumber daya, seperti database relasional. Pendekatan ini adalah praktik terbaik ketika pengembang bekerja di lebih dari satu cabang sekaligus.

Pengujian di cloud sangat berharga untuk semua fase pengujian, termasuk pengujian unit, pengujian integrasi, dan pengujian ujung ke ujung. Mempertahankan isolasi yang tepat sangat penting; tetapi Anda masih ingin lingkungan QA Anda menyerupai lingkungan produksi Anda sedekat mungkin. Untuk alasan ini, tim menambahkan proses kontrol perubahan untuk lingkungan QA.

Untuk lingkungan pra-produksi dan produksi, batasan biasanya ditarik di tingkat akun untuk melindungi beban kerja dari masalah tetangga yang bising dan menerapkan kontrol keamanan hak istimewa terendah untuk melindungi data sensitif. Beban kerja memiliki kuota. Anda tidak ingin pengujian Anda menggunakan kuota yang dialokasikan untuk produksi (tetangga yang bising) atau memiliki akses ke data pelanggan. Pengujian beban adalah aktivitas lain yang harus Anda isolasi dari tumpukan produksi Anda.

Dalam semua kasus, lingkungan harus dikonfigurasi dengan peringatan dan kontrol untuk menghindari pengeluaran yang tidak perlu. Misalnya, Anda dapat membatasi jenis, tingkat, atau ukuran sumber daya yang dapat dibuat, dan mengatur peringatan email ketika perkiraan biaya melebihi ambang batas tertentu.

Gunakan tiruan untuk logika bisnis terisolasi

Kerangka kerja tiruan adalah alat yang berharga untuk menulis tes unit cepat. Mereka sangat bermanfaat ketika tes mencakup logika bisnis internal yang kompleks, seperti perhitungan atau simulasi matematika atau keuangan. Cari pengujian unit yang memiliki sejumlah besar kasus uji atau variasi input, di mana input tersebut tidak mengubah pola atau konten panggilan ke layanan cloud lainnya.

Kode yang dicakup oleh pengujian unit dengan tiruan juga harus dicakup oleh pengujian di cloud. Ini direkomendasikan karena laptop pengembang atau lingkungan mesin build dapat dikonfigurasi secara berbeda dari lingkungan produksi di cloud. Misalnya, fungsi Lambda Anda dapat menggunakan lebih banyak memori atau waktu daripada yang dialokasikan saat dijalankan dengan parameter input tertentu. Atau kode Anda mungkin menyertakan variabel lingkungan yang tidak dikonfigurasi dengan cara yang sama (atau sama sekali), dan perbedaan dapat menyebabkan kode berperilaku berbeda atau gagal.

Manfaat tiruan kurang untuk tes integrasi, karena tingkat upaya untuk menerapkan tiruan yang diperlukan meningkat dengan jumlah titik koneksi. End-to-end pengujian tidak boleh menggunakan tiruan, karena tes ini umumnya menangani keadaan dan logika kompleks yang tidak dapat dengan mudah disimulasikan dengan kerangka kerja tiruan.

Terakhir, hindari menggunakan layanan cloud yang diejek untuk memvalidasi implementasi panggilan layanan yang tepat. Sebaliknya, lakukan panggilan layanan cloud di cloud untuk memvalidasi perilaku, konfigurasi, dan implementasi fungsional.

Gunakan emulator dengan hemat

Emulator dapat nyaman untuk beberapa kasus penggunaan, misalnya, untuk tim pengembangan dengan akses internet yang terbatas, tidak dapat diandalkan, atau lambat. Tetapi, dalam kebanyakan keadaan, pilihlah untuk menggunakan emulator dengan hemat.

Dengan menghindari emulator, Anda dapat membangun dan berinovasi dengan fitur layanan terbaru dan API terbaru. Anda tidak terjebak menunggu rilis vendor untuk mencapai paritas fitur. Anda mengurangi biaya di muka dan berkelanjutan untuk pembelian dan konfigurasi pada beberapa sistem pengembangan dan membangun mesin. Selain itu, Anda menghindari masalah bahwa banyak layanan cloud tidak memiliki emulator yang tersedia. Strategi pengujian yang bergantung pada emulasi membuat tidak mungkin untuk menggunakan layanan tersebut (yang mengarah ke solusi yang berpotensi lebih mahal) atau menghasilkan kode dan konfigurasi yang tidak diuji dengan baik.

Ketika Anda menggunakan emulasi untuk pengujian, Anda masih harus menguji di cloud untuk memverifikasi konfigurasi dan menguji interaksi dengan layanan cloud yang hanya dapat disimulasikan atau diejek di lingkungan yang ditiru.

Tantangan pengujian secara lokal

Saat Anda menggunakan emulator dan panggilan yang diejek untuk menguji di desktop lokal Anda, Anda mungkin mengalami inkonsistensi pengujian saat kode Anda berkembang dari lingkungan ke lingkungan dalam pipeline Anda. CI/CD Tes unit untuk memvalidasi logika bisnis aplikasi Anda di desktop Anda mungkin tidak secara akurat menguji aspek-aspek penting dari layanan cloud.

Contoh berikut memberikan kasus yang harus diperhatikan saat menguji secara lokal dengan tiruan dan emulator:

Contoh: Fungsi Lambda membuat bucket S3

Jika logika fungsi Lambda bergantung pada pembuatan bucket S3, pengujian lengkap harus mengonfirmasi bahwa Amazon S3 dipanggil dan bucket berhasil dibuat.

• Dalam pengaturan pengujian tiruan, Anda mungkin mengejek respons sukses dan berpotensi menambahkan kasus uji untuk menangani respons kegagalan.

• Dalam skenario pengujian emulasi, CreateBucket API mungkin dipanggil, tetapi Anda harus menyadari bahwa identitas yang membuat panggilan lokal tidak berasal dari layanan Lambda. Identitas panggilan tidak mengambil peran keamanan seperti di cloud, jadi otentikasi placeholder digunakan sebagai gantinya, mungkin dengan peran yang lebih permisif atau identitas pengguna yang berbeda ketika dijalankan di cloud.

Pengaturan tiruan dan emulasi menguji apa yang dilakukan fungsi Lambda jika memanggil Amazon S3; namun, pengujian tersebut tidak memverifikasi bahwa fungsi Lambda, seperti yang dikonfigurasi, mampu berhasil membuat bucket Amazon S3. Anda harus memastikan peran yang ditetapkan untuk fungsi memiliki kebijakan keamanan terlampir yang memungkinkan fungsi untuk melakukan s3:CreateBucket tindakan. Jika tidak, fungsi kemungkinan gagal saat digunakan ke lingkungan cloud.

Contoh: Fungsi Lambda memproses pesan dari antrian Amazon SQS

Jika antrian Amazon SQS adalah sumber fungsi Lambda, pengujian lengkap harus memverifikasi bahwa fungsi Lambda berhasil dipanggil saat pesan dimasukkan ke dalam antrian.

Pengujian emulasi dan pengujian tiruan umumnya diatur untuk menjalankan kode fungsi Lambda secara langsung, dan untuk mensimulasikan integrasi Amazon SQS dengan meneruskan muatan peristiwa JSON (atau objek deserialisasi) sebagai input pengendali fungsi.

Pengujian lokal yang mensimulasikan integrasi Amazon SQS menguji apa yang dilakukan fungsi Lambda ketika dipanggil oleh Amazon SQS dengan muatan tertentu, tetapi pengujian tidak memverifikasi bahwa Amazon SQS berhasil memanggil fungsi Lambda saat digunakan ke lingkungan cloud.

Beberapa contoh masalah konfigurasi yang mungkin Anda temui dengan Amazon SQS dan Lambda meliputi:

• Waktu tunggu visibilitas Amazon SQS terlalu rendah, mengakibatkan beberapa pemanggilan ketika hanya satu yang dimaksudkan.

• Peran eksekusi fungsi Lambda tidak mengizinkan membaca pesan dari antrian (melaluisqs:ReceiveMessage,sqs:DeleteMessage, atausqs:GetQueueAttributes).

• Contoh peristiwa yang diteruskan ke fungsi Lambda melebihi kuota ukuran pesan Amazon SQS. Oleh karena itu, tes ini tidak valid karena Amazon SQS tidak akan pernah dapat mengirim pesan sebesar itu.

Seperti yang ditunjukkan contoh-contoh ini, tes yang mencakup logika bisnis tetapi bukan konfigurasi antara layanan cloud cenderung memberikan hasil yang tidak dapat diandalkan.

Pertanyaan yang Sering Diajukan

Saya memiliki fungsi Lambda yang melakukan perhitungan dan mengembalikan hasil tanpa memanggil layanan lain. Apakah saya benar-benar perlu mengujinya di cloud?

Ya. Fungsi lambda memiliki parameter konfigurasi yang dapat mengubah hasil pengujian. Semua kode fungsi Lambda memiliki ketergantungan pada batas waktu dan pengaturan memori, yang dapat menyebabkan fungsi gagal jika pengaturan tersebut tidak diatur dengan benar.

Kebijakan Lambda juga memungkinkan pencatatan keluaran standar ke Amazon CloudWatch. Bahkan jika kode Anda tidak memanggil CloudWatch secara langsung, izin diperlukan untuk mengaktifkan logging. Izin yang diperlukan ini tidak dapat diejek atau ditiru secara akurat.

Bagaimana pengujian di cloud dapat membantu pengujian unit? Jika ada di cloud dan terhubung ke sumber daya lain, bukankah itu tes integrasi?

Kami mendefinisikan pengujian unit sebagai pengujian yang beroperasi pada komponen arsitektur secara terpisah, tetapi ini tidak mencegah pengujian memasukkan komponen yang mungkin memanggil layanan lain atau menggunakan beberapa komunikasi jaringan.

Banyak aplikasi tanpa server memiliki komponen arsitektur yang dapat diuji secara terpisah, bahkan di cloud. Salah satu contohnya adalah fungsi Lambda yang mengambil input, memproses data, dan mengirim pesan ke antrian Amazon SQS. Tes unit fungsi ini kemungkinan akan menguji apakah nilai input menghasilkan nilai tertentu yang ada dalam pesan yang diantri.

Pertimbangkan tes yang ditulis dengan menggunakan pola Arrange, Act, Assert:

• A tur: Alokasikan sumber daya (antrian untuk menerima pesan, dan fungsi yang diuji).

• Tind akan: Panggil fungsi yang sedang diuji.

• Men egaskan: Ambil pesan yang dikirim oleh fungsi, dan validasi output.

Pendekatan pengujian tiruan akan melibatkan mengejek antrian dengan objek tiruan dalam proses, dan membuat instance dalam proses dari kelas atau modul yang berisi kode fungsi Lambda. Selama fase Assert, pesan antrian akan diambil dari objek yang diejek.

Dalam pendekatan berbasis cloud, pengujian akan membuat antrian Amazon SQS untuk tujuan pengujian, dan akan menerapkan fungsi Lambda dengan variabel lingkungan yang dikonfigurasi untuk menggunakan antrian Amazon SQS yang terisolasi sebagai tujuan keluaran. Setelah menjalankan fungsi Lambda, pengujian akan mengambil pesan dari antrian Amazon SQS.

Pengujian berbasis cloud akan menjalankan kode yang sama, menegaskan perilaku yang sama, dan memvalidasi kebenaran fungsional aplikasi. Namun, itu akan memiliki keuntungan tambahan karena dapat memvalidasi pengaturan fungsi Lambda: peran IAM, kebijakan IAM, dan batas waktu fungsi dan pengaturan memori.

Langkah dan sumber daya selanjutnya

Gunakan sumber daya berikut untuk mempelajari lebih lanjut dan mengeksplorasi contoh praktis pengujian.

Contoh implementasi

Repositori Sampel Uji https://github.com/aws-samples/serverless-test-samples Tanpa Server GitHub berisi contoh konkret pengujian yang mengikuti pola dan praktik terbaik yang dijelaskan dalam panduan ini. Repositori berisi kode sampel dan panduan panduan dari proses tiruan, emulasi, dan pengujian cloud yang dijelaskan di bagian sebelumnya. Gunakan repositori ini untuk mendapatkan panduan pengujian tanpa server terbaru dari AWS.

Bacaan lebih lanjut

Kunjungi Serverless Land untuk mengakses blog, video, dan pelatihan terbaru untuk teknologi AWS tanpa server.

Posting AWS blog berikut juga direkomendasikan untuk dibaca:

• Mempercepat pengembangan tanpa server dengan Ac AWS SAM celerate (posting AWS blog)

• Meningkatkan kecepatan pengembangan dengan CDK Watch (posting AWS blog)

• Integrasi layanan mengejek dengan AWS Step Functions Local (posting AWS blog)

• Memulai pengujian aplikasi tanpa server (posting AWS blog)

Alat

• AWS SAM — Meng uji dan men-debug aplikasi tanpa server

• AWS SAM - Meng integrasikan dengan tes otomatis

• Lambda — Meng uji fungsi Lambda di konsol Lambda