Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Go

Pengujian Kode Data-Intensif dengan Go, Bagian 3

by
Difficulty:IntermediateLength:MediumLanguages:
This post is part of a series called Testing Data-Intensive Code with Go.
Testing Data-Intensive Code With Go, Part 2
Testing Data-Intensive Code With Go, Part 4

Indonesian (Bahasa Indonesia) translation by Ari Ana (you can also view the original English article)

Ikhtisar

Ini adalah bagian tiga dari dari lima dalam seri tutorial tentang pengujian kode data-intensif dengan Go. Pada bagian kedua, saya membahas pengujian terhadap lapisan data nyata dalam-memori berdasarkan SQLite yang populer. Dalam tutorial ini, saya akan melakukan pengujian terhadap lapisan data kompleks lokal yang menyertakan DB relasional dan cache Redis.

Pengujian Terhadap Lapisan Data Lokal

Pengujian terhadap lapisan data dalam-memori adalah luar biasa. Pengujiannya cepat, dan Anda memiliki kontrol penuh. Tetapi terkadang Anda harus lebih dekat dengan konfigurasi sebenarnya dari lapisan data produksi Anda. Berikut beberapa kemungkinan alasannya:

  • Anda menggunakan detail spesifik dari DB relasional Anda yang ingin Anda uji.
  • Lapisan data Anda terdiri dari beberapa penyimpanan data yang saling berinteraksi.
  • Kode yang diuji terdiri dari beberapa proses yang mengakses lapisan data yang sama.
  • Anda ingin mempersiapkan atau mengamati data uji Anda menggunakan alat standar.
  • Anda tidak ingin menerapkan lapisan data dalam-memori khusus jika lapisan data Anda berubah-ubah.
  • Anda hanya ingin tahu bahwa Anda menguji terhadap lapisan data Anda yang sebenarnya.
  • Anda perlu menguji dengan banyak data yang tidak sesuai dalam memori.

Saya yakin ada alasan lain, tetapi Anda dapat melihat mengapa hanya menggunakan sebuah lapisan data dalam-memori untuk pengujian mungkin tidak cukup dalam banyak kasus.

OK. Jadi kami ingin menguji lapisan data yang sebenarnya. Tapi kita tetap ingin menjadi seringan dan selincah mungkin. Itu berarti lapisan data lokal. Berikut manfaatnya:

  • Tidak perlu menyediakan dan mengkonfigurasi apa pun di pusat data atau cloud.
  • Tidak perlu khawatir tentang pengujian kami yang merusak data produksi secara tidak sengaja.
  • Tidak perlu berkoordinasi dengan sesama pengembang di lingkungan pengujian bersama.
  • Tidak ada kelambatan selama panggilan jaringan.
  • Kontrol penuh atas konten lapisan data, dengan kemampuan untuk memulai dari awal setiap saat.

Dalam tutorial ini kita akan menaikkan taruhannya. Kami akan mengimplementasikan (sebagian) lapisan data hibrid yang terdiri dari DB relasional MariaDB dan server Redis. Kemudian kita akan menggunakan Docker untuk membuat lapisan data lokal yang dapat kita gunakan dalam pengujian kami.

Menggunakan Docker untuk Menghindari Sakit Kepala Saat Instalasi

Pertama, Anda membutuhkan Docker, tentu saja. Lihat dokumentasinya jika Anda tidak terbiasa dengan Docker. Langkah selanjutnya adalah mendapatkan image untuk penyimpanan data kami: MariaDB dan Redis. Tanpa terlalu banyak detail, MariaDB adalah DB relasional hebat yang kompatibel dengan MySQL, dan Redis adalah penyimpanan kunci-nilai dalam-memori yang hebat (dan masih banyak lagi).

Sekarang setelah Docker diinstal dan kami memiliki image untuk MariaDB dan Redis, kami dapat menulis file docker-compose.yml, yang akan kami gunakan untuk meluncurkan penyimpanan data kami. Mari kita memanggil DB kami "songify".

Anda dapat meluncurkan penyimpanan data Anda dengan perintah docker-compose up (mirip dengan vagrant up). Keluarannya akan terlihat seperti ini:

Pada titik ini, Anda memiliki server MariaDB lengkap mendengarkan pada port 3306 dan server Redis mendengarkan pada port 6379 (keduanya adalah port standar).

Lapisan Data Hibrid

Mari manfaatkan penyimpanan data yang kuat ini dan tingkatkan lapisan data kami ke lapisan data hibrid yang menyimpan lagu-lagu per pengguna dalam Redis. Ketika GetSongsByUser() dipanggil, lapisan data akan memeriksa dulu apakah Redis sudah menyimpan lagu untuk pengguna. Jika itu kemudian hanya mengembalikan lagu dari Redis, tetapi jika tidak (cache miss) maka akan mengambil lagu-lagu dari MariaDB dan mengisi cache Redis, sehingga siap untuk waktu berikutnya.

Berikut adalah definisi struct dan constructor. Struct ini menyimpan handle DB seperti sebelumnya dan juga klien redis. Constructor menghubungkan ke DB relasional serta Redis. Ini menciptakan skema dan flushes redis hanya jika parameter yang sesuai adalah true, yang diperlukan hanya untuk pengujian. Dalam produksi, Anda membuat skema sekali (mengabaikan migrasi skema).

Menggunakan MariaDB

MariaDB dan SQLite sedikit berbeda sejauh DDL berjalan. Perbedaannya kecil, tetapi penting. Go tidak memiliki piranti lintas-DB yang matang seperti SQLAlchemy yang fantastis dari Python, jadi Anda harus mengelolanya sendiri (tidak, Gorm tidak dihitung). Perbedaan utama adalah:

  • Driver SQL adalah "github.com/go-sql-driver/mysql".
  • Database tidak hidup dalam memori, sehingga dibuat ulang setiap kali (drop dan create).
  • Skema harus merupakan bagian dari pernyataan DDL independen, bukan satu string dari semua pernyataan.
  • Primary key auto increment ditandai oleh AUTO_INCREMENT.
  • VARCHAR bukannya TEXT.

Berikut ini kodenya:

Menggunakan Redis

Redis sangat mudah digunakan dari Go. Perpustakaan klien "github.com/go-redis/redis" sangat intuitif dan setia mengikuti perintah Redis. Sebagai contoh, untuk menguji apakah sebuah kunci ada, Anda hanya menggunakan metode Exists() dari klien redis, yang menerima satu atau lebih kunci dan mengembalikan berapa banyak dari mereka ada.

Dalam hal ini, saya memeriksa satu kunci saja:

Menguji Akses ke Banyak Penyimpanan Data

Pengujiannya sebenarnya identik. Antarmuka tidak berubah, dan perilaku tidak berubah. Satu-satunya perubahan adalah bahwa implementasi sekarang menyimpan cache di Redis. Metode GetSongsByEmail() sekarang hanya memanggil refreshUser_Redis().

Metode refreshUser_Redis() mengembalikan lagu-lagu pengguna dari Redis jika ada dan sebaliknya mengambilnya dari MariaDB.

Ada sedikit masalah di sini dari sudut pandang metodologi pengujian. Ketika kami menguji melalui antarmuka lapisan data abstrak, kami tidak memiliki visibilitas ke dalam implementasi lapisan data.

Sebagai contoh, ada kemungkinan bahwa ada cacat besar di mana lapisan data benar-benar melompati cache dan selalu mengambil data dari DB. Pengujian akan dilalui, tetapi kami tidak mendapatkan manfaat dari cache. Saya akan berbicara di bagian lima tentang menguji cache Anda, yang sangat penting.

Kesimpulan

Dalam tutorial ini, kami membahas pengujian terhadap lapisan data kompleks lokal yang terdiri dari banyak penyimpanan data (DB relasional dan cache Redis). Kami juga menggunakan Docker untuk menyebarkan banyak penyimpanan data dengan mudah untuk diuji.

Di bagian empat, kami akan fokus pada pengujian terhadap penyimpanan data jarak jauh, menggunakan snapshot data produksi untuk pengujian kami, dan juga menghasilkan data uji kami sendiri. Nantikanlah!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.