Pengujian unit memungkinkan Anda memeriksa kualitas kode setelah menulisnya, tetapi Anda juga dapat menggunakan pengujian unit untuk meningkatkan proses pengembangan seiring progres Anda. Daripada menulis pengujian setelah Anda selesai mengembangkan aplikasi, sebaiknya tulis pengujian seiring progres Anda. Hal ini membantu Anda mendesain unit kode yang kecil, mudah dikelola, dan dapat digunakan kembali. Hal ini juga memudahkan Anda menguji kode secara menyeluruh dan cepat.
Saat melakukan pengujian unit lokal, Anda menjalankan pengujian yang tetap berada di dalam lingkungan pengembangan Anda sendiri tanpa melibatkan komponen jarak jauh. App Engine menyediakan utilitas pengujian yang menggunakan implementasi lokal datastore dan layanan App Engine lainnya. Ini berarti Anda dapat menerapkan penggunaan kode Anda atas layanan ini secara lokal, tanpa men-deploy kode ke App Engine, dengan menggunakan service stub.
Service stub adalah metode yang menyimulasikan perilaku layanan. Misalnya, service stub datastore yang ditampilkan dalam Menulis Pengujian Datastore dan Memcache memungkinkan Anda menguji kode datastore tanpa membuat permintaan ke datastore sebenarnya. Setiap entity yang disimpan selama pengujian unit datastore akan disimpan di memori, bukan di datastore, dan dihapus setelah pengujian dijalankan. Anda dapat menjalankan pengujian kecil dan cepat tanpa dependensi pada datastore itu sendiri.
Dokumen ini menjelaskan cara menulis pengujian unit pada beberapa layanan App Engine lokal, lalu memberikan sejumlah informasi tentang penyiapan framework pengujian.
Memperkenalkan aplikasi utilitas pengujian Python 2
Modul App Engine Python yang disebut
testbed
menyediakan stub layanan untuk pengujian unit.
Stub layanan tersedia untuk layanan berikut:
- Identitas Aplikasi
init_app_identity_stub
- Blobstore (gunakan
init_blobstore_stub
) - Kemampuan (gunakan
init_capability_stub
) - Datastore (gunakan
init_datastore_v3_stub
) - File (gunakan
init_files_stub
) - Gambar (hanya untuk
dev_appserver;
gunakan
init_images_stub
) - LogService (gunakan
init_logservice_stub
) - Email (gunakan
init_mail_stub
) - Memcache (gunakan
init_memcache_stub
) - Antrean Tugas (gunakan
init_taskqueue_stub
) - Pengambilan URL (gunakan
init_urlfetch_stub
) - Layanan pengguna (gunakan
init_user_stub
)
Untuk melakukan inisialisasi semua stub secara bersamaan, Anda dapat menggunakan init_all_stubs
.
Menulis pengujian Datastore dan memcache
Bagian ini menunjukkan contoh cara menulis kode yang menguji penggunaan layanan datastore dan memcache.
Pastikan runner pengujian Anda memiliki library yang sesuai di jalur pemuatan
Python, termasuk library App Engine, yaml
(disertakan dalam App Engine
SDK), root aplikasi, dan modifikasi lainnya pada jalur library
yang diharapkan oleh kode aplikasi (seperti direktori ./lib
lokal, jika ada
). Contoh:
import sys
sys.path.insert(1, 'google-cloud-sdk/platform/google_appengine')
sys.path.insert(1, 'google-cloud-sdk/platform/google_appengine/lib/yaml/lib')
sys.path.insert(1, 'myapp/lib')
Impor modul unittest
Python dan modul App Engine yang relevan
dengan layanan yang sedang diuji—dalam hal ini memcache
dan ndb
, yang menggunakan
datastore dan memcache. Impor juga
modul
testbed
.
Lalu, buat class TestModel
. Dalam contoh ini, fungsi melakukan pemeriksaan untuk melihat apakah entity disimpan dalam memcache. Jika tidak ada entity yang ditemukan, entity akan diperiksa di datastore. Hal ini sering kali berulang di kondisi nyata, karena ndb
menggunakan memcache sendiri di belakang layar, tetapi ini masih merupakan pola yang bagus untuk
pengujian.
Selanjutnya, buat kasus pengujian. Apa pun layanan yang Anda uji, kasus pengujian
harus membuat instance Testbed
dan mengaktifkannya. Kasus pengujian juga harus
menginisialisasi stub layanan yang relevan. Dalam hal ini, menggunakan
init_datastore_v3_stub
dan init_memcache_stub
. Metode untuk menginisialisasi
stub layanan App Engine lainnya tercantum dalam Memperkenalkan Utilitas Pengujian
Python.
Metode init_datastore_v3_stub()
tanpa argumen menggunakan datastore
dalam memori yang awalnya kosong. Jika Anda ingin menguji entity datastore
yang ada, sertakan nama jalurnya sebagai argumen untuk init_datastore_v3_stub()
.
Selain setUp()
, sertakan metode tearDown()
yang menonaktifkan
testbed. Tindakan ini akan memulihkan stub asli sehingga pengujian tidak mengganggu
satu sama lain.
Kemudian, terapkan pengujian.
Sekarang Anda dapat menggunakan TestModel
untuk menulis pengujian yang menggunakan stub layanan datastore atau memcache, alih-alih menggunakan layanan sebenarnya.
Misalnya, metode yang ditampilkan di bawah membuat dua entity: entity pertama menggunakan
nilai default untuk atribut number
(42), dan entity kedua menggunakan
nilai non-default untuk number
(17). Metode tersebut kemudian membuat kueri untuk
entity TestModel
, tetapi hanya untuk entity dengan nilai default number
.
Setelah mengambil semua entity yang cocok, metode ini akan menguji bahwa hanya satu entity
yang ditemukan, dan bahwa nilai atribut number
entity tersebut adalah nilai
default.
Sebagai contoh lainnya, metode berikut membuat entity dan mengambilnya
menggunakan fungsi GetEntityViaMemcache()
yang kita buat di atas. Metode ini
kemudian menguji bahwa entity ditampilkan, dan bahwa nilai number
-nya sama
dengan entity yang dibuat sebelumnya.
Terakhir, panggil unittest.main()
.
Untuk menjalankan pengujian, lihat Menjalankan pengujian.
Menulis pengujian Cloud Datastore
Jika aplikasi Anda menggunakan Cloud Datastore, Anda mungkin ingin menulis
pengujian yang memverifikasi perilaku aplikasi dalam menghadapi konsistensi
tertunda.
db.testbed
menampilkan opsi yang mempermudah
hal ini:
Class PseudoRandomHRConsistencyPolicy
memungkinkan Anda mengontrol kemungkinan penerapan penulisan sebelum setiap kueri global (non-ancestor). Dengan menetapkan
probabilitas ke 0%, kami menginstruksikan stub datastore agar beroperasi dengan
jumlah konsistensi maksimum. Konsistensi akhir maksimum berarti
penulisan akan di-commit tetapi selalu gagal diterapkan, sehingga kueri global (non-ancestor)
akan terus gagal melihat perubahan. Hal ini tentu saja tidak mewakili
jumlah konsistensi akhir yang akan dilihat aplikasi Anda saat berjalan dalam
produksi, tetapi untuk tujuan pengujian, sangat berguna untuk dapat mengonfigurasi
datastore lokal agar berperilaku seperti ini setiap saat. Jika Anda menggunakan probabilitas
bukan nol, PseudoRandomHRConsistencyPolicy
akan membuat urutan keputusan
konsistensi yang deterministik sehingga hasil pengujiannya konsisten:
API pengujian berguna untuk memverifikasi bahwa aplikasi Anda berperilaku dengan baik
dalam menghadapi konsistensi tertunda, tetapi perlu diingat bahwa model konsistensi
pembacaan Replikasi Tinggi lokal adalah perkiraan dari model konsistensi
pembacaan Replikasi Tinggi produksi, bukan replika yang sama persis. Di lingkungan
lokal, menjalankan get()
dari Entity
yang termasuk dalam grup entity
dengan penulisan yang belum diterapkan akan selalu membuat hasil penulisan yang belum diterapkan
terlihat oleh kueri global berikutnya. Dalam produksi, hal ini tidak terjadi.
Menulis pengujian email
Anda dapat menggunakan stub layanan email untuk menguji layanan email. Serupa dengan layanan lain yang didukung oleh testbed, pertama-tama Anda melakukan inisialisasi stub, lalu memanggil kode yang menggunakan mail API, dan akhirnya menguji apakah pesan yang benar telah dikirim.
Menulis pengujian task queue
Anda dapat menggunakan stub taskqueue untuk menulis pengujian yang menggunakan layanan taskqueue. Serupa dengan layanan lain yang didukung oleh testbed, pertama-tama lakukanlah inisialisasi stub, lalu panggil kode yang menggunakan taskqueue API, dan terakhir uji apakah tugas ditambahkan dengan benar ke antrean.
Menyetel file konfigurasi queue.yaml
Jika ingin menjalankan pengujian pada kode yang berinteraksi dengan antrean non-default, Anda harus
membuat dan menentukan file queue.yaml
yang akan digunakan aplikasi Anda.
Berikut inilah contoh queue.yaml
:
Untuk mengetahui informasi selengkapnya tentang opsi queue.yaml yang tersedia, lihat konfigurasi task queue.
Lokasi queue.yaml
ditentukan saat melakukan inisialisasi stub:
self.testbed.init_taskqueue_stub(root_path='.')
Dalam contoh ini, queue.yaml
berada di direktori yang sama dengan pengujian. Jika ada di
folder lain, jalur tersebut harus ditentukan di root_path
.
Memfilter tugas
get_filtered_tasks
stub tugas memungkinkan Anda memfilter tugas yang diantrekan.
Hal ini mempermudah penulisan pengujian yang perlu memverifikasi kode yang mengantrekan
beberapa tugas.
Menulis pengujian tugas yang ditangguhkan
Jika kode aplikasi Anda menggunakan library yang ditangguhkan, Anda dapat menggunakan stub
taskqueue bersama dengan deferred
untuk memverifikasi bahwa fungsi yang ditangguhkan telah dimasukkan ke dalam antrean dan
dieksekusi dengan benar.
Mengubah variabel lingkungan default
Layanan App Engine sering kali bergantung pada variabel lingkungan. Metode activate()
class testbed.Testbed
menggunakan nilai default, tetapi Anda dapat menetapkan nilai
kustom berdasarkan kebutuhan pengujian dengan metode setup_env
class testbed.Testbed
.
Misalnya, Anda memiliki pengujian yang menyimpan beberapa entity di
datastore, semuanya ditautkan ke ID aplikasi yang sama. Sekarang Anda ingin menjalankan
pengujian yang sama lagi, tetapi menggunakan ID aplikasi yang berbeda dari ID aplikasi yang
ditautkan ke entity tersimpan. Untuk melakukannya, teruskan nilai baru ke
self.setup_env()
sebagai app_id
.
Contoh:
Menyimulasikan login
Penggunaan sering lainnya untuk setup_env
adalah untuk menyimulasikan pengguna yang sedang login,
baik dengan atau tanpa hak istimewa admin, untuk memeriksa apakah pengendali Anda beroperasi
dengan benar dalam setiap kasus.
Sekarang, metode pengujian Anda dapat memanggil, misalnya, self.loginUser('', '')
untuk
menyimulasikan tidak ada pengguna yang login, self.loginUser('test@example.com', '123')
untuk
menyimulasikan pengguna non-admin yang login, self.loginUser('test@example.com',
'123', is_admin=True)
untuk menyimulasikan pengguna admin yang sedang login.
Menyiapkan framework pengujian
Aplikasi utilitas pengujian SDK tidak terikat dengan framework tertentu. Anda dapat menjalankan pengujian unit dengan testrunner App Engine yang tersedia, misalnya nose- gae atau ferrisnose. Anda juga dapat menulis testrunner sederhana sendiri, atau menggunakan testrunner yang ditampilkan di bawah ini.
Skrip berikut menggunakan modul unittest Python.
Anda dapat memberi nama skrip tersebut sesuai keinginan. Saat Anda menjalankannya, berikan jalur ke penginstalan Google Cloud CLI atau Google App Engine SDK dan jalur ke modul pengujian Anda. Skrip akan menemukan semua pengujian di jalur yang disediakan dan akan
mencetak hasilnya ke aliran data error standar. File pengujian yang mengikuti konvensi memiliki test
yang diawali dengan namanya.
Menjalankan pengujian
Anda dapat menjalankan pengujian ini hanya dengan menjalankan skrip runner.py
, yang dijelaskan secara mendetail di bagian Menyiapkan framework pengujian:
python runner.py <path-to-appengine-or-gcloud-SDK> .