Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk menguji aplikasi tanpa server

Bagian berikut menguraikan praktik terbaik untuk mencapai cakupan yang efektif saat menguji aplikasi tanpa server.

Prioritaskan pengujian di cloud

Untuk aplikasi yang dirancang dengan baik, Anda dapat menggunakan berbagai teknik pengujian untuk memenuhi berbagai persyaratan dan kondisi. Namun, berdasarkan perkakas saat ini, kami menyarankan Anda untuk fokus pada pengujian di cloud sebanyak mungkin. Meskipun pengujian di cloud dapat menciptakan latensi pengembang, meningkatkan biaya, dan terkadang memerlukan investasi dalam DevOps kontrol tambahan, teknik ini memberikan cakupan pengujian yang paling andal, akurat, dan lengkap.

Anda harus memiliki akses ke lingkungan terisolasi untuk melakukan pengujian. Idealnya, setiap pengembang harus memiliki dedicated Akun AWS untuk menghindari masalah dengan penamaan sumber daya yang dapat terjadi ketika beberapa pengembang yang bekerja dalam kode yang sama mencoba menerapkan atau memanggil panggilan API pada sumber daya yang memiliki nama yang identik. Lingkungan ini harus dikonfigurasi dengan peringatan dan kontrol yang sesuai 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.

Jika Anda harus berbagi satu Akun AWS dengan pengembang lain, proses pengujian otomatis harus memberi nama sumber daya yang unik untuk setiap pengembang. Misalnya, memperbarui skrip atau file konfigurasi TOMB yang menyebabkan perintah AWS SAM CLI sam deploy atau sam sync dapat secara otomatis menentukan nama tumpukan yang menyertakan nama pengguna pengembang lokal.

Pengujian di cloud sangat berharga untuk semua fase pengujian, termasuk pengujian unit, pengujian integrasi, dan end-to-end pengujian.

Gunakan tiruan jika perlu

Kerangka kerja tiruan adalah alat yang berharga untuk menulis tes unit cepat. Mereka sangat berharga ketika tes perlu 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 tidak mengubah pola atau konten panggilan ke layanan cloud lainnya. Membuat tes tiruan untuk skenario ini dapat meningkatkan waktu iterasi pengembang.

Kode yang dicakup oleh pengujian unit yang menggunakan pengujian tiruan juga harus dicakup oleh pengujian di cloud. Ini diperlukan karena tiruan masih berjalan di laptop pengembang atau mesin build, dan lingkungan mungkin dikonfigurasi secara berbeda dari yang ada di cloud. Misalnya, kode Anda mungkin menyertakan AWS Lambda fungsi yang menggunakan lebih banyak memori atau membutuhkan waktu lebih lama daripada yang dikonfigurasi Lambda untuk 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.

Jangan gunakan tiruan layanan cloud untuk memvalidasi implementasi yang tepat dari integrasi layanan tersebut. Meskipun mungkin dapat diterima untuk mengejek layanan cloud saat Anda menguji fungsionalitas lain, Anda harus menguji panggilan layanan cloud di cloud untuk memvalidasi konfigurasi dan implementasi fungsional yang benar.

Mocks dapat menambah nilai pada pengujian unit, terutama ketika Anda sering menguji sejumlah besar kasus. Manfaat ini berkurang untuk tes integrasi, karena tingkat upaya untuk mengimplementasikan tiruan yang diperlukan meningkat dengan jumlah titik koneksi. End-to-endpengujian tidak boleh menggunakan tiruan, karena pengujian ini umumnya berurusan dengan status dan logika kompleks yang tidak dapat dengan mudah disimulasikan dengan kerangka kerja tiruan.

Memahami pengorbanan pengujian emulasi

Emulator dapat menjadi pilihan praktis untuk kasus penggunaan tertentu. Misalnya, tim pengembangan dengan akses internet yang terbatas, tidak konsisten, atau lambat mungkin menemukan bahwa pengujian emulasi adalah cara yang paling dapat diandalkan untuk mengulangi kode sebelum pindah ke lingkungan cloud.

Untuk sebagian besar keadaan lain, gunakan emulator secara selektif. Ketika Anda sangat bergantung pada emulator, akan sulit untuk memasukkan fitur AWS layanan baru ke dalam pengujian Anda sampai vendor emulasi merilis pembaruan untuk memberikan paritas fitur. Emulator juga memerlukan investasi awal dan berkelanjutan untuk pengaturan dan konfigurasi di seluruh sistem pengembangan dan membangun mesin. Selain itu, banyak layanan cloud tidak memiliki emulator yang tersedia; memilih strategi emulasi-pertama dapat menghalangi penggunaan layanan tersebut atau menghasilkan kode dan konfigurasi yang tidak diuji dengan baik terhadap perilaku layanan nyata.

Jika Anda menggunakan pengujian emulasi, lengkapi dengan pengujian cloud sebanyak mungkin untuk memvalidasi bahwa konfigurasi cloud yang tepat sudah ada dan untuk menguji interaksi dengan layanan yang hanya dapat disimulasikan atau diejek di lingkungan yang ditiru.

Pengujian emulasi dapat memberikan umpan balik cepat untuk pengujian unit dan, tergantung pada fitur dan paritas perilaku perangkat lunak emulasi, dapat mendukung beberapa integrasi dan end-to-end pengujian juga.

Tes lingkup melalui batas-batas alam

Ketika aplikasi tanpa server tumbuh di lebih banyak komponen arsitektur, batas-batas alami muncul di sekitar subsistem—terutama ketika mengikuti praktik terbaik seperti fungsi tujuan tunggal dan decoupling berbasis peristiwa. Batas-batas ini berfungsi sebagai tepi pengujian yang efektif di mana Anda dapat memvalidasi kontrak antar komponen.

Identifikasi batas-batas arsitektur

Cari jahitan alami dalam desain aplikasi Anda:

Pisahkan kode Lambda dari logika bisnis

Sederhanakan pengujian Anda dengan mengisolasi kode Lambda dari logika bisnis inti. Handler Lambda Anda harus bertindak sebagai adaptor tipis antara AWS runtime dan logika aplikasi Anda. Itu harus mengekstrak dan memvalidasi data peristiwa dan kemudian mendelegasikan ke fungsi yang dapat diuji yang tidak memiliki dependensi Lambda. Ini membuat logika bisnis Anda portabel, lebih mudah dipikirkan, dan mudah diuji tanpa mengejek objek Lambda atau menyiapkan lingkungan yang kompleks.

Perlakukan batas sebagai kontrak

Uji di batas, bukan melalui itu. Validasi apa yang melintasi tepi tanpa memerlukan seluruh sistem hilir. Batas-batas yang sama ini juga berfungsi sebagai kait observabilitas dalam produksi. Lapisan arsitektur tempat Anda menguji dapat diinstrumentasi untuk pemantauan menggunakan Amazon CloudWatch Log, AWS X-Ray jejak, dan EventBridge peristiwa.

Gunakan test harness untuk alur kerja asinkron

Aplikasi tanpa server sering mengandalkan pola asinkron, di mana peristiwa memicu pemrosesan, pesan mengalir melalui antrian, dan alur kerja menjangkau beberapa layanan tanpa tanggapan langsung. Anda tidak bisa begitu saja memanggil fungsi dan memeriksa nilai yang dikembalikan. Hasilnya mungkin muncul kemudian dalam database, aliran log, atau layanan lain.

Test harness sedang menguji infrastruktur yang Anda terapkan bersama aplikasi Anda untuk mengamati dan memvalidasi perilaku asinkron ini. Test harness biasanya meliputi:

Kode pengujian Anda memulai suatu peristiwa, menunggu alur kerja selesai, lalu menanyakan harness pengujian untuk memverifikasi hasil yang diharapkan terjadi.

Berikut ini adalah praktik terbaik:

Test harness paling berharga untuk pengujian integrasi yang memvalidasi alur kerja di beberapa layanan, end-to-end pengujian yang memverifikasi perjalanan pengguna yang lengkap, dan arsitektur berbasis peristiwa tempat layanan berkomunikasi melalui, Amazon SNS, Amazon SQS, atau EventBridge Amazon Kinesis.

Mengatur lingkungan cloud untuk isolasi pengembang

Pengujian di cloud membutuhkan lingkungan yang terisolasi satu sama lain. Ketika pengembang berbagi satu Akun AWS, seperti akun pengembangan tim, pertimbangkan untuk membuat tumpukan aplikasi terpisah untuk setiap pengembang atau cabang fitur. Ini mengisolasi sumber daya, mencegah tabrakan penamaan, dan menghindari pertengkaran kuota atau masalah tetangga yang bising selama pengujian.

Gunakan AWS Systems Manager Parameter Store atau perkakas serupa untuk mengelola konfigurasi khusus tumpukan, seperti titik akhir API dan nama antrian. Untuk efisiensi biaya, bagikan sumber daya yang mahal seperti kluster Amazon Relational Database Service (Amazon RDS) di seluruh tumpukan pengembang sambil menjaga sumber daya tanpa server yang ringan (seperti fungsi Lambda, tahapan API Gateway, dan tabel DynamoDB) terisolasi per tumpukan.

Dalam industri yang diatur, kebijakan keamanan perusahaan dapat membatasi akses pengembang ke lingkungan cloud, sehingga sulit untuk menjalankan pengujian cloud sebagai bagian dari alur kerja pengembangan lokal. Dalam kasus ini, pengujian emulasi dapat mengisi kesenjangan antara pengujian tiruan lokal dan validasi cloud penuh, meskipun harus dilengkapi dengan pengujian cloud kapan pun akses memungkinkan.

Mempercepat loop umpan balik

Saat Anda menguji di cloud, gunakan alat dan teknik untuk mempercepat loop umpan balik pengembangan. Misalnya, gunakan mode AWS SAM Accelerate dan AWS CDK watch untuk mengurangi waktu yang diperlukan untuk mendorong modifikasi kode ke lingkungan cloud. Sampel dalam repositori Sampel Uji GitHub Tanpa Server mengeksplorasi beberapa teknik ini.

Kami juga menyarankan Anda membuat dan menguji sumber daya cloud dari komputer lokal Anda 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, kemampuan untuk mengotomatiskan penerapan dari mesin pengembangan membantu Anda menemukan masalah konfigurasi cloud lebih cepat dan mengurangi upaya yang sia-sia dari memperbarui dan menyetujui modifikasi ke kontrol sumber.