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. Pengujian berbasis cloud akan memberikan ukuran kualitas yang paling akurat dari fungsi dan aplikasi tanpa server Anda.

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

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

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

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

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

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

• E nd-to-end tes - Tes yang memverifikasi perilaku di seluruh aplikasi. Misalnya, memastikan infrastruktur diatur dengan benar dan bahwa peristiwa mengalir antar layanan seperti yang diharapkan untuk merekam pesanan pelanggan.

Hasil bisnis yang ditargetkan

Menguji solusi tanpa server mungkin memerlukan sedikit lebih banyak waktu untuk menyiapkan pengujian yang memverifikasi interaksi berbasis peristiwa antar layanan. Ingatlah alasan bisnis praktis berikut saat Anda membaca panduan ini:

• Tingkatkan kualitas aplikasi Anda

• Kurangi waktu untuk membangun fitur dan memperbaiki bug

Kualitas aplikasi tergantung pada pengujian berbagai skenario untuk memverifikasi fungsionalitas. Mempertimbangkan skenario bisnis dengan cermat dan mengotomatiskan pengujian tersebut untuk dijalankan terhadap layanan cloud akan meningkatkan kualitas aplikasi Anda.

Bug perangkat lunak dan masalah konfigurasi memiliki dampak paling kecil pada biaya dan jadwal ketika tertangkap selama siklus pengembangan berulang. Jika masalah tetap tidak terdeteksi selama pengembangan, menemukan dan memperbaiki produksi membutuhkan lebih banyak usaha oleh lebih banyak orang.

Strategi pengujian tanpa server yang terencana dengan baik akan meningkatkan kualitas perangkat lunak dan meningkatkan waktu iterasi dengan memverifikasi fungsi dan aplikasi Lambda Anda berfungsi seperti yang diharapkan di lingkungan cloud.

Apa yang harus diuji

Sebaiknya gunakan strategi pengujian yang menguji perilaku layanan terkelola, konfigurasi cloud, kebijakan keamanan, dan integrasi dengan kode Anda untuk meningkatkan kualitas perangkat lunak. Pengujian perilaku, juga dikenal sebagai pengujian kotak hitam, memverifikasi sistem berfungsi seperti yang diharapkan tanpa mengetahui semua internal.

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

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

• Periksa apakah suatu peristiwa melewati semua layanan yang diharapkan end-to-end dalam alur kerja.

Dalam arsitektur berbasis server tradisional, tim sering mendefinisikan ruang lingkup pengujian untuk hanya menyertakan kode yang berjalan pada server aplikasi. Komponen, layanan, atau dependensi lainnya sering dianggap eksternal dan di luar ruang lingkup untuk pengujian.

Aplikasi tanpa server sering terdiri dari unit kerja kecil, seperti fungsi Lambda yang mengambil produk dari database, atau memproses item dari antrian, atau mengubah ukuran gambar dalam penyimpanan. Setiap komponen berjalan di lingkungan mereka sendiri. Tim kemungkinan akan bertanggung jawab atas banyak unit kecil ini dalam satu aplikasi.

Beberapa fungsi aplikasi dapat didelegasikan sepenuhnya ke layanan terkelola seperti Amazon S3, atau dibuat tanpa menggunakan kode yang dikembangkan secara internal. Tidak perlu menguji layanan terkelola ini, tetapi Anda perlu menguji integrasi dengan layanan ini.

Cara menguji tanpa server

Anda mungkin akrab dengan cara menguji aplikasi yang digunakan secara lokal: Anda menulis tes yang berjalan terhadap kode yang berjalan sepenuhnya di sistem operasi desktop Anda, atau di dalam wadah. Misalnya, Anda dapat memanggil komponen layanan web lokal dengan permintaan dan kemudian membuat pernyataan tentang respons.

Solusi tanpa server dibuat dari kode fungsi dan layanan terkelola berbasis cloud, seperti antrian, database, bus acara, dan sistem pesan. Semua komponen ini terhubung melalui arsitektur berbasis peristiwa, di mana pesan, yang disebut peristiwa, mengalir dari satu sumber daya ke sumber daya lainnya. Interaksi ini dapat sinkron, seperti ketika layanan web segera mengembalikan hasil, atau tindakan asinkron yang selesai di lain waktu, seperti menempatkan item dalam antrian atau memulai langkah alur kerja. Strategi pengujian Anda harus mencakup kedua skenario dan menguji interaksi antar layanan. Untuk interaksi asinkron, Anda mungkin perlu mendeteksi efek samping pada komponen hilir yang mungkin tidak segera diamati.

Mereplikasi seluruh lingkungan cloud, termasuk antrian, tabel database, bus acara, kebijakan keamanan, dan banyak lagi, tidak praktis. Anda pasti akan mengalami masalah karena perbedaan antara lingkungan lokal Anda dan lingkungan yang Anda gunakan di cloud. Variasi antara lingkungan Anda akan meningkatkan waktu untuk mereproduksi dan memperbaiki bug.

Dalam aplikasi tanpa server, komponen arsitektur umumnya ada seluruhnya di cloud, jadi pengujian terhadap kode dan layanan di cloud diperlukan untuk mengembangkan fitur dan memperbaiki bug.

Teknik pengujian

Pada kenyataannya, strategi pengujian Anda kemungkinan akan mencakup campuran teknik untuk meningkatkan kualitas solusi Anda. Anda akan menggunakan tes interaktif cepat untuk men-debug fungsi di konsol, pengujian unit otomatis untuk memeriksa logika bisnis yang terisolasi, verifikasi panggilan ke layanan eksternal dengan tiruan, dan pengujian sesekali terhadap emulator yang meniru layanan.

• Pengujian di cloud - Anda menyebarkan infrastruktur dan kode untuk menguji dengan layanan aktual, kebijakan keamanan, konfigurasi, dan parameter spesifik infrastruktur. Pengujian berbasis cloud memberikan ukuran kualitas kode yang paling akurat.

  Mendebug fungsi di konsol adalah cara cepat untuk menguji di cloud. Anda dapat memilih dari pustaka peristiwa pengujian sampel atau membuat acara khusus untuk menguji fungsi secara terpisah. Anda juga dapat berbagi acara pengujian melalui konsol dengan tim Anda.

  Untuk mengotomatiskan pengujian dalam siklus hidup pengembangan dan pembuatan, Anda perlu menguji di luar konsol. Lihat bagian pengujian khusus bahasa dalam panduan ini untuk strategi dan sumber daya otomatisasi.

• Pengujian dengan tiruan (juga disebut palsu) - Mocks adalah objek dalam kode Anda yang mensimulasikan dan berdiri untuk layanan eksternal. Mocks memberikan perilaku yang telah ditentukan sebelumnya untuk memverifikasi panggilan dan parameter layanan. Palsu adalah implementasi tiruan yang mengambil jalan pintas untuk menyederhanakan atau meningkatkan kinerja. Misalnya, objek akses data palsu mungkin mengembalikan data dari datastore dalam memori. Mocks dapat meniru dan menyederhanakan dependensi yang kompleks, tetapi juga dapat menyebabkan lebih banyak tiruan untuk menggantikan dependensi bersarang.

• Pengujian dengan emulator - Anda dapat mengatur aplikasi (terkadang dari pihak ketiga) untuk meniru layanan cloud di lingkungan lokal Anda. Kecepatan adalah kekuatan mereka, tetapi pengaturan dan paritas dengan layanan produksi adalah kelemahan mereka. Gunakan emulator dengan hemat.

Pengujian di cloud

Pengujian di cloud sangat berharga untuk semua fase pengujian, termasuk pengujian unit, pengujian integrasi, dan end-to-end pengujian. Saat menjalankan pengujian terhadap kode berbasis cloud yang juga berinteraksi dengan layanan berbasis cloud, Anda mendapatkan ukuran kualitas kode yang paling akurat.

Cara mudah untuk menjalankan fungsi Lambda di cloud adalah dengan acara pengujian di. AWS Management ConsolePeristiwa pengujian adalah input JSON ke fungsi Anda. Jika fungsi Anda tidak memerlukan input, acara dapat berupa dokumen ({}) JSON kosong. Konsol menyediakan contoh peristiwa untuk berbagai integrasi layanan. Setelah membuat acara di konsol, Anda juga dapat membagikannya dengan tim Anda untuk membuat pengujian lebih mudah dan konsisten.

Pelajari cara men-debug fungsi sampel di konsol.

catatan

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

Sampel otomatisasi pengujian tersedia di repositori 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 berinteraksi dengan sumber daya berbasis cloud. Sumber daya ini telah digunakan menggunakan alat baris AWS SAM perintah AWS Serverless Application Model dan. Kode pengujian pertama-tama mengambil output tumpukan yang diterapkan, yang mencakup titik akhir API, fungsi ARN, dan peran keamanan. Selanjutnya, pengujian mengirimkan permintaan ke titik akhir API, yang merespons dengan daftar bucket Amazon S3. Pengujian ini berjalan sepenuhnya terhadap sumber daya berbasis cloud untuk memverifikasi sumber daya tersebut digunakan, diamankan, dan berfungsi seperti yang diharapkan.

========================= 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-west-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

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

        PythonTestDemoIamRole
        = arn:aws:iam::1234567890: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-west-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.

• Tes cloud meningkatkan kepercayaan bahwa kode Anda akan berjalan dengan benar dalam produksi.

Pengujian di cloud memang memiliki beberapa kelemahan. Hal negatif yang paling jelas dari pengujian di cloud adalah bahwa penyebaran ke lingkungan cloud biasanya membutuhkan waktu lebih lama daripada penerapan ke lingkungan desktop lokal.

Untungnya, alat seperti AWS Serverless Application Model (AWS SAM) Accelerate, mode tontonan AWS Cloud Development Kit (AWS CDK), dan SST (pihak ke-3) mengurangi latensi yang terlibat dengan iterasi penyebaran cloud. Alat-alat ini dapat memantau infrastruktur dan kode Anda dan secara otomatis menyebarkan pembaruan tambahan ke lingkungan cloud Anda.

catatan

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

Tidak seperti pengujian lokal, pengujian di cloud membutuhkan sumber daya tambahan yang dapat menimbulkan biaya layanan. Membuat lingkungan pengujian yang terisolasi dapat meningkatkan beban DevOps tim Anda, terutama di organisasi dengan kontrol ketat seputar akun dan infrastruktur. Meski begitu, ketika bekerja dengan skenario infrastruktur yang kompleks, biaya dalam waktu pengembang untuk mengatur dan memelihara lingkungan lokal yang rumit bisa serupa (atau lebih mahal) daripada menggunakan lingkungan pengujian sekali pakai yang dibuat dengan Infrastruktur sebagai alat otomatisasi Kode.

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 pengujian yang menggunakan tiruan layanan Amazon S3 yang mengembalikan respons tertentu setiap kali metode CreateObjectdipanggil. Saat pengujian berjalan, tiruan mengembalikan respons terprogram tersebut tanpa memanggil Amazon S3, atau titik akhir layanan lainnya.

Objek tiruan sering dihasilkan oleh kerangka kerja tiruan untuk mengurangi upaya pengembangan. Beberapa kerangka kerja tiruan bersifat generik dan yang lainnya dirancang khusus untuk AWS SDK, seperti Moto, pustaka Python untuk layanan dan sumber daya ejekan. AWS

Perhatikan bahwa objek tiruan berbeda dari emulator karena tiruan biasanya dibuat atau dikonfigurasi oleh pengembang sebagai bagian dari kode pengujian, sedangkan emulator adalah aplikasi mandiri yang mengekspos fungsionalitas dengan cara yang sama seperti sistem yang mereka tiru.

Keuntungan menggunakan tiruan meliputi:

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

• Mocks 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.

• Mocks 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 kerja tiruan generik, Anda dapat mensimulasikan fitur baru segera setelah AWS SDK yang diperbarui tersedia.

Pengujian tiruan memiliki kelemahan ini:

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

• Mocks ditulis, dikonfigurasi, dan harus dikelola oleh pengembang, meningkatkan tanggung jawab mereka.

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

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

• Pengujian yang menggunakan tiruan mungkin lolos 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 atau batasan kuota AWS Identity and Access Management (IAM) and Access Management (IAM). Meskipun tiruan lebih baik dalam mensimulasikan ketika otorisasi gagal atau kuota terlampaui, pengujian tidak dapat menentukan hasil mana yang benar-benar akan terjadi di lingkungan produksi.

Pengujian dengan emulasi

Emulator biasanya merupakan aplikasi yang berjalan secara lokal yang meniru layanan produksi. AWS

Emulator memiliki API yang mirip dengan rekan cloud mereka dan memberikan nilai pengembalian yang serupa. Mereka juga dapat mensimulasikan perubahan status yang diprakarsai oleh panggilan API. Misalnya, Anda dapat menggunakan AWS SAM untuk menjalankan fungsi dengan AWS SAM lokal untuk meniru layanan Lambda sehingga Anda dapat dengan cepat memanggil fungsi. Lihat AWS SAM lokal di Panduan AWS Serverless Application Model Pengembang untuk detailnya.

Keuntungan dari tes dengan emulator meliputi:

• Emulator dapat memfasilitasi 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 n-tier, Anda mungkin memiliki mesin database dan server web, mirip dengan yang berjalan dalam produksi, berjalan di mesin lokal Anda untuk menyediakan kemampuan pengujian 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.

Pengujian dengan emulator memiliki kelemahan ini:

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

• Fitur dan API yang ditiru 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 mengandalkan emulator dapat memberikan hasil yang sukses secara lokal, tetapi gagal di cloud karena kebijakan keamanan produksi, konfigurasi antar-layanan, atau melebihi kuota Lambda.

• Banyak AWS layanan tidak memiliki emulator yang tersedia. Jika Anda mengandalkan emulasi, Anda mungkin tidak memiliki opsi pengujian yang memuaskan untuk bagian dari aplikasi Anda.

Praktik terbaik

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

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

Prioritaskan pengujian di cloud

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

Struktur kode Anda untuk pengujian

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

Penangan fungsi Lambda Anda harus berupa adaptor ramping yang mengambil data peristiwa dan hanya meneruskan detail yang penting bagi metode logika bisnis Anda. Dengan strategi ini, Anda dapat membungkus tes komprehensif seputar logika bisnis Anda tanpa mengkhawatirkan detail khusus Lambda. 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 masukan 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 tontonan AWS CDK mengurangi waktu yang diperlukan untuk memperbarui lingkungan cloud.

Sampel dalam repositori Sampel Uji GitHub 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 sia-sia untuk pembaruan dan proses peninjauan kode.

Fokus pada tes integrasi

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

Tes yang dijalankan terhadap dua atau lebih komponen arsitektur disebut tes integrasi. Tujuan dari tes integrasi adalah untuk memahami tidak hanya bagaimana kode Anda akan dijalankan di seluruh komponen, tetapi bagaimana lingkungan hosting kode Anda akan berperilaku. nd-to-end Tes E adalah jenis tes integrasi khusus yang memverifikasi perilaku di seluruh aplikasi.

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

Misalnya, sistem yang diuji bisa berupa aplikasi yang menggunakan API Gateway, Lambda, dan DynamoDB. Pengujian dapat membuat panggilan HTTP sintetis ke titik akhir API Gateway dan memvalidasi bahwa respons tersebut menyertakan muatan yang diharapkan. Tes ini memvalidasi bahwa kode AWS Lambda sudah benar, dan setiap layanan dikonfigurasi dengan benar untuk menangani permintaan, termasuk izin IAM di antara mereka. Selanjutnya, Anda dapat merancang tes untuk menulis catatan dari berbagai ukuran untuk memverifikasi kuota layanan Anda, seperti ukuran catatan maksimal 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 akan menghindari konflik dengan penamaan sumber daya yang dapat terjadi ketika beberapa pengembang bekerja di basis kode bersama, mencoba menerapkan sumber daya, atau menjalankan API.

Proses pengujian otomatis harus membuat sumber daya bernama unik untuk setiap tumpukan. Misalnya, Anda dapat mengatur skrip atau file konfigurasi TOMB sehingga perintah AWS SAM CLI sam deploy atau sam sync akan 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 menyediakan dan mengkonfigurasi. Misalnya, database dapat 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 end-to-end pengujian. 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 pada tingkat akun untuk melindungi beban kerja dari masalah tetangga yang bising dan menerapkan kontrol keamanan hak istimewa paling sedikit untuk melindungi data sensitif. Beban kerja memiliki kuota. Anda tidak ingin pengujian Anda mengkonsumsi 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 yang 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 perbedaannya dapat menyebabkan kode berperilaku berbeda atau gagal.

Manfaat tiruan kurang untuk tes integrasi, karena tingkat upaya untuk mengimplementasikan tiruan yang diperlukan meningkat dengan jumlah titik koneksi. nd-to-end Pengujian E tidak boleh menggunakan tiruan, karena tes ini umumnya berurusan dengan status dan logika kompleks yang tidak dapat dengan mudah disimulasikan dengan kerangka kerja tiruan.

Terakhir, hindari menggunakan layanan cloud tiruan untuk memvalidasi implementasi panggilan layanan yang tepat. Sebagai gantinya, 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 terbatas, tidak dapat diandalkan, atau lambat. Tetapi, dalam kebanyakan keadaan, pilih untuk menggunakan emulator dengan hemat.

Dengan menghindari emulator, Anda akan dapat membangun dan berinovasi dengan fitur layanan terbaru dan API terbaru. Anda tidak akan terjebak menunggu rilis vendor untuk mencapai paritas fitur. Anda akan mengurangi biaya di muka dan berkelanjutan untuk pembelian dan konfigurasi pada beberapa sistem pengembangan dan membangun mesin. Selain itu, Anda akan menghindari masalah bahwa banyak layanan cloud tidak memiliki emulator yang tersedia. Strategi pengujian yang bergantung pada emulasi akan 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 untuk 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 tiruan untuk menguji di desktop lokal Anda, Anda mungkin mengalami inkonsistensi pengujian saat kode Anda berkembang dari lingkungan ke lingkungan di pipeline CI/CD Anda. Pengujian unit untuk memvalidasi logika bisnis aplikasi Anda di desktop Anda mungkin tidak secara akurat menguji 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, CreateBucketAPI mungkin dipanggil, tetapi Anda perlu menyadari bahwa identitas yang membuat panggilan lokal tidak akan berasal dari layanan Lambda. Identitas panggilan tidak akan mengambil peran keamanan seperti di cloud, sehingga otentikasi placeholder akan digunakan sebagai gantinya, mungkin dengan peran yang lebih permisif atau identitas pengguna yang akan berbeda saat dijalankan di cloud.

Pengaturan tiruan dan emulasi akan menguji apa yang akan dilakukan fungsi Lambda jika memanggil Amazon S3; namun, tes tersebut tidak akan memverifikasi bahwa fungsi Lambda, seperti yang dikonfigurasi, mampu berhasil membuat bucket Amazon S3. Anda harus memastikan peran yang ditetapkan ke fungsi memiliki kebijakan keamanan terlampir yang memungkinkan fungsi untuk melakukan s3:CreateBucket tindakan. Jika tidak, fungsi tersebut kemungkinan akan gagal saat diterapkan 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 antrean.

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

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

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

• Batas waktu visibilitas Amazon SQS terlalu rendah, menghasilkan beberapa pemanggilan ketika hanya satu yang dimaksudkan.

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

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

Seperti yang ditunjukkan oleh 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 pengaturan batas waktu dan 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 menelepon 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 dari memasukkan komponen yang dapat 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 antrian.

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

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

• Tindakan: Panggil fungsi yang sedang diuji.

• Tegaskan: 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 antrean Amazon SQS untuk keperluan 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 dan pengaturan memori fungsi.

Langkah dan sumber daya selanjutnya

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

Contoh implementasi

Repositori Sampel Uji Tanpa Server pada GitHub berisi contoh nyata pengujian yang mengikuti pola dan praktik terbaik yang dijelaskan dalam panduan ini. Repositori berisi kode sampel dan panduan panduan dari proses pengujian tiruan, emulasi, dan cloud yang dijelaskan di bagian sebelumnya. Gunakan repositori ini untuk mempercepat panduan pengujian tanpa server terbaru dari. AWS

Bacaan lebih lanjut

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

Posting AWS blog berikut juga disarankan untuk dibaca:

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

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

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

• Memulai dengan menguji aplikasi tanpa server (AWS posting blog)

Alat

• AWS SAM — Menguji dan men-debug aplikasi tanpa server

• AWS SAM — Mengintegrasikan dengan tes otomatis

• Lambda - Menguji fungsi Lambda di konsol Lambda