Pengujian Kode Data-Intensif Dengan Go, Bagian 1

() translation by (you can also view the original English article)

Ikhtisar

Banyak sistem non-trivial juga bersifat data-intensif atau data-driven. Menguji bagian-bagian sistem yang bersifat data-intensif sangat berbeda dari pengujian sistem-sistem intensif-kode. Pertama, mungkin ada banyak kecanggihan di lapisan data itu sendiri, seperti penyimpanan data hibrid, caching, backup, dan redundansi.

Semua mesin ini tidak ada hubungannya dengan aplikasi itu sendiri, tetapi harus diuji. Kedua, kode mungkin sangat generik, dan untuk mengujinya, Anda perlu menghasilkan data yang terstruktur dengan cara tertentu. Dalam rangkaian lima tutorial ini, saya akan membahas semua aspek ini, menjelajahi beberapa strategi untuk merancang sistem data-intensif yang dapat diuji dengan Go, dan menyelami contoh-contoh spesifik.

Pada bagian pertama, saya akan membahas desain lapisan data abstrak yang memungkinkan pengujian yang tepat, bagaimana melakukan penanganan kesalahan pada lapisan data, cara meniru kode akses data, dan cara menguji terhadap lapisan data abstrak.

Pengujian Terhadap Lapisan Data

Berurusan dengan penyimpanan data nyata dan seluk-beluknya rumit dan tidak terkait dengan logika bisnis. Konsep lapisan data memungkinkan Anda untuk mengekspos antarmuka yang rapi ke data Anda dan menyembunyikan detail besar tentang bagaimana data disimpan dan bagaimana cara mengaksesnya. Saya akan menggunakan aplikasi sampel yang disebut "Songify" untuk manajemen musik pribadi untuk mengilustrasikan konsep dengan kode nyata.

Merancang Layer Data Abstrak

Mari tinjau domain pengelolaan musik pribadi—pengguna dapat menambahkan lagu dan memberi label mereka—dan mempertimbangkan data apa yang perlu kami simpan dan cara mengaksesnya. Objek di domain kami adalah pengguna, lagu, dan label. Ada dua kategori operasi yang ingin Anda lakukan pada data apa pun: kueri (read-only) dan perubahan status (create, update, delete). Berikut ini adalah antarmuka dasar untuk lapisan data:

package abstract_data_layer

import "time"

type Song struct {
    Url         string
  Name        string
	Description string
}

type Label struct {
	Name string
}

type User struct {
	Name         string
	Email        string
	RegisteredAt time.Time
	LastLogin    time.Time
}

type DataLayer interface {
	// Queries (read-only)
	GetUsers() ([]User, error)
	GetUserByEmail(email string) (User, error)
	GetLabels() ([]Label, error)
	GetSongs() ([]Song, error)
	GetSongsByUser(user User) ([]Song, error)
	GetSongsByLabel(label string) ([]Song, error)

	// State changing operations
	CreateUser(user User) error
	ChangeUserName(user User, name string) error
	AddLabel(label string) error
	AddSong(user User, song Song, labels []Label) error
}

Perhatikan bahwa tujuan dari model domain ini adalah menyajikan lapisan data sederhana namun tidak sepenuhnya sepele untuk menunjukkan aspek pengujian. Tentunya, dalam aplikasi nyata akan ada lebih banyak objek seperti album, genre, artis, dan banyak lagi informasi tentang setiap lagu. Jika dorongan datang untuk mendorong, Anda selalu dapat menyimpan informasi acak tentang lagu dalam deskripsinya, serta melampirkan sebanyak mungkin label yang Anda inginkan.

Dalam praktiknya, Anda mungkin ingin membagi lapisan data Anda menjadi beberapa antarmuka. Beberapa struct mungkin memiliki lebih banyak atribut, dan metode mungkin memerlukan lebih banyak argumen (misal. Semua metode GetXXX() mungkin akan memerlukan beberapa argumen paging). Anda mungkin memerlukan antarmuka dan metode akses data lainnya untuk operasi pemeliharaan seperti pemuatan massal, pencadangan, dan migrasi. Terkadang masuk akal untuk mengekspos antarmuka akses data asynchronous sebagai gantinya atau di samping antarmuka sinkron.

Apa yang kami peroleh dari lapisan data abstrak ini?

One-stop shop untuk operasi akses data.
Pandangan yang jelas tentang persyaratan manajemen data aplikasi kami dalam hal domain.
Kemampuan untuk mengubah implementasi lapisan data konkret sesuka hati.
Kemampuan untuk mengembangkan domain/logika bisnis lapisan awal terhadap antarmuka sebelum lapisan data konkret selesai atau stabil.
Terakhir tapi bukan yang akhir, kemampuan untuk meniru lapisan data untuk pengujian yang cepat dan fleksibel dari domain/logika bisnis.

Error dan Penanganan Error di Lapisan Data

Data dapat disimpan di beberapa toko data terdistribusi, di beberapa kluster di berbagai lokasi geografis dalam kombinasi pusat data on-premise dan cloud.

Akan ada kegagalan, dan kegagalan itu perlu ditangani. Idealnya, kesalahan penanganan logika (retries, timeout, pemberitahuan kegagalan bencana) dapat ditangani oleh lapisan data konkret. Kode logika domain hanya akan mendapatkan kembali data atau kesalahan umum ketika data tidak dapat dijangkau.

Dalam beberapa kasus, logika domain mungkin menginginkan akses yang lebih terperinci ke data dan memilih strategi penggantian dalam situasi tertentu (misalnya hanya sebagian data yang tersedia karena bagian dari kluster tidak dapat diakses, atau data sudah basi karena cache tidak disegarkan). Aspek-aspek tersebut memiliki implikasi untuk desain lapisan data Anda dan untuk pengujiannya.

Sejauh pengujian berjalan, Anda harus mengembalikan kesalahan Anda sendiri didefinisikan dalam lapisan data abstrak dan memetakan semua pesan kesalahan konkret ke jenis kesalahan Anda sendiri atau bergantung pada pesan kesalahan yang sangat generik.

Tiruan Kode Akses Data

Mari kita tiru lapisan data kita. Tujuan dari tiruan ini adalah untuk menggantikan lapisan data nyata selama tes. Yang membutuhkan lapisan data tiruan untuk mengekspos antarmuka yang sama dan untuk dapat menanggapi setiap urutan metode dengan respons yang direkam (atau dihitung).

Selain itu, berguna untuk melacak berapa kali setiap metode dipanggil. Saya tidak akan menunjukkannya di sini, tetapi bahkan dimungkinkan untuk melacak urutan panggilan ke metode yang berbeda dan argumen mana yang dilewatkan ke masing-masing metode untuk memastikan rantai panggilan tertentu.

Berikut adalah struktur lapisan data tiruan.

package concrete_data_layer

import (
    . "abstract_data_layer"
)


const (
	GET_USERS = iota
	GET_USER_BY_EMAIL 
	GET_LABELS          
	GET_SONGS
	GET_SONGS_BY_USER
	GET_SONG_BY_LABEL
	ERRORS            
)

type MockDataLayer struct {
	Errors                  []error
	GetUsersResponses       [][]User
	GetUserByEmailResponses []User
	GetLabelsResponses      [][]Label
	GetSongsResponses       [][]Song
	GetSongsByUserResponses [][]Song
	GetSongsByLabelResponses[][]Song
	Indices                 []int
}

func NewMockDataLayer() MockDataLayer {
	return MockDataLayer{Indices: []int{0, 0, 0, 0, 0, 0, 0, 0}}
}

Pernyataan const mencantumkan semua operasi yang didukung dan kesalahannya. Setiap operasi memiliki indeks tersendiri dalam irisan Indices. Indeks untuk setiap operasi mewakili berapa kali metode yang bersangkutan dipanggil serta apa tanggapan dan kesalahan berikutnya seharusnya.

Untuk setiap metode yang memiliki nilai kembalian selain kesalahan, ada potongan tanggapan. Ketika metode tiruan dipanggil, respons dan kesalahan yang sesuai (berdasarkan indeks untuk metode ini) dikembalikan. Untuk metode yang tidak memiliki nilai balik kecuali kesalahan, Anda tidak perlu menentukan potongan XXXResponses.

Perhatikan bahwa Kesalahan dibagi oleh semua metode. Itu berarti bahwa jika Anda ingin menguji serangkaian panggilan, Anda harus menyuntikkan jumlah kesalahan yang benar dalam urutan yang benar. Desain alternatif akan digunakan untuk setiap respons pasangan yang terdiri dari nilai dan kesalahan kembali. The NewMockDataLayer() mengembalikan fungsi struktur layer data tiruan baru dengan semua indeks diinisialisasi ke nol.

Berikut adalah implementasi metode GetUsers(), yang menggambarkan konsep-konsep ini.

func(m *MockDataLayer) GetUsers() (users []User, err error) {
    i := m.Indices[GET_USERS]
	users = m.GetUsersResponses[i]
	if len(m.Errors) > 0 {
		err = m.Errors[m.Indices[ERRORS]]
		m.Indices[ERRORS]++
	}
	m.Indices[GET_USERS]++
	return
}

Baris pertama mendapat indeks saat ini dari operasi GET_USERS (akan menjadi 0 awalnya).

Baris kedua mendapat respons untuk indeks saat ini.

Baris ketiga hingga kelima menugaskan kesalahan indeks saat ini jika bidang Errors diisi dan menaikkan indeks kesalahan. Saat menguji jalan yang bahagia, kesalahannya akan nihil. Untuk membuatnya lebih mudah digunakan, Anda dapat menghindari menginisialisasi bidang Errors dan kemudian setiap metode akan mengembalikan nil untuk kesalahan.

Baris berikutnya akan menambahkan indeks, sehingga panggilan berikutnya akan mendapatkan respons yang tepat.

Baris terakhir baru kembali. Nilai pengembalian bernama untuk pengguna dan kesalahan sudah diisi (atau nol secara default untuk kesalahan).

Berikut ini metode lain, GetLabels(), yang mengikuti pola yang sama. Satu-satunya perbedaan adalah indeks mana yang digunakan dan koleksi tanggapan rekaman apa yang digunakan.

func(m *MockDataLayer) GetLabels() (labels []Label, err error) {
    i := m.Indices[GET_LABELS]
	labels = m.GetLabelsResponses[i]
	if len(m.Errors) > 0 {
		err = m.Errors[m.Indices[ERRORS]]
		m.Indices[ERRORS]++
	}
	m.Indices[GET_LABELS]++
	return
}

Ini adalah contoh utama dari kasus penggunaan di mana generik dapat menyimpan banyak kode boiler. Mungkin untuk memanfaatkan refleksi untuk efek yang sama, tetapi di luar lingkup tutorial ini. Yang utama diambil di sini adalah bahwa lapisan data tiruan dapat mengikuti pola tujuan umum dan mendukung setiap skenario pengujian, seperti yang akan Anda lihat segera.

Bagaimana dengan beberapa metode yang hanya mengembalikan kesalahan? Lihat metode CreateUser(). Ini lebih sederhana karena hanya menangani kesalahan dan tidak perlu mengelola respons terekam.

func(m *MockDataLayer) CreateUser(user User) (err error) {
    if len(m.Errors) > 0 {
		i := m.Indices[CREATE_USER]
		err = m.Errors[m.Indices[ERRORS]]
		m.Indices[ERRORS]++
	}
	return
}

Lapisan data tiruan ini hanyalah contoh dari apa yang diperlukan untuk meniru antarmuka dan menyediakan beberapa layanan yang berguna untuk diuji. Anda dapat datang dengan implementasi tiruan Anda sendiri atau menggunakan perpustakaan tiruan yang tersedia. Bahkan ada framework GoMock standar.

Saya pribadi menemukan kerangka kerja tiruan yang mudah diimplementasikan dan lebih memilih untuk menggulung sendiri (sering menghasilkannya secara otomatis) karena saya menghabiskan sebagian besar waktu pengembangan saya menulis tes dan meniru dependensi. YMMV.

Pengujian Terhadap Lapisan Data Abstrak

Sekarang kita memiliki lapisan data tiruan, mari tulis beberapa tes terhadapnya. Sangat penting untuk menyadari bahwa di sini kita tidak menguji lapisan data itu sendiri. Kami akan menguji lapisan data itu sendiri dengan metode lain nantinya dalam seri ini. Tujuannya di sini adalah untuk menguji logika kode yang bergantung pada lapisan data abstrak.

Misalnya, anggap pengguna ingin menambahkan lagu, tetapi kami memiliki kuota 100 lagu per pengguna. Perilaku yang diharapkan adalah jika pengguna memiliki kurang dari 100 lagu dan lagu yang ditambahkan adalah baru, itu akan ditambahkan. Jika lagu sudah ada kemudian kembali kesalahan "Duplikasi lagu". Jika pengguna telah memiliki 100 lagu kemudian kembali kesalahan "Melebihi kuota lagu".

Mari menulis tes untuk kasus uji ini menggunakan lapisan data tiruan kami. Ini adalah tes kotak putih, yang berarti Anda perlu mengetahui metode mana dari lapisan data yang sedang diuji kode yang akan dipanggil dan di mana urutan sehingga Anda dapat mengisi tanggapan tiruan dan kesalahan dengan benar. Jadi pendekatan tes pertama tidak ideal di sini. Mari kita menulis kode pertama.

Berikut ini adalah SongManager struct. Itu tergantung hanya pada lapisan data abstrak. Yang akan memungkinkan Anda untuk lulus pelaksanaan lapisan data nyata dalam produksi, tetapi lapisan data tiruan selama pengujian.

SongManager sendiri benar-benar agnostik terhadap implementasi konkrit dari antarmuka DataLayer. SongManager struct juga menerima pengguna, yang disimpannya. Agaknya, setiap pengguna aktif memiliki instance SongManager sendiri, dan pengguna hanya dapat menambahkan lagu untuk mereka sendiri. Fungsi NewSongManager() memastikan antarmuka DataLayer input tidak nol.

package song_manager

import (
    "errors"
	. "abstract_data_layer"
)


const (
	MAX_SONGS_PER_USER = 100
)


type SongManager struct {
    user User
	dal DataLayer
}

func NewSongManager(user User, 
                    dal DataLayer) (*SongManager, error) {
	if dal == nil {
		return nil, errors.New("DataLayer can't be nil")
	}
	return &SongManager{user, dal}, nil
}

Mari kita menerapkan metode AddSong(). Metode ini memanggil getSongsByUser() data layer pertama, dan kemudian melewati beberapa pemeriksaan. Jika semuanya OK, itu memanggil metode AddSong() data layer dan mengembalikan hasilnya.

func(lm *SongManager) AddSong(newSong Song, 
                              labels []Label) error {
    songs, err := lm.dal.GetSongsByUser(lm.user)
	if err != nil {
		return nil
	}

	// Check if song is a duplicate
	for _, song := range songs {
		if song.Url == newSong.Url {
			return errors.New("Duplicate song")
		}
	}

	// Check if user has max number of songs
	if len(songs) == MAX_SONGS_PER_USER {
		return errors.New("Song quota exceeded")
	}

	return lm.dal.AddSong(user, newSong, labels)
}

Melihat kode ini, Anda dapat melihat bahwa ada dua kasus uji lain yang kami abaikan: panggilan ke metode lapisan data GetSongByUser() dan AddSong() mungkin gagal karena alasan lain. Sekarang, dengan penerapan SongManager.AddSong() di depan kami, kami dapat menulis tes komprehensif yang mencakup semua kasus penggunaan. Mari kita mulai dengan jalan yang menyenangkan. Metode TestAddSong_Success() membuat pengguna bernama Gigi dan lapisan data tiruan.

Ini mengisi bidang GetSongsByUserResponses dengan irisan yang berisi irisan kosong, yang akan menghasilkan irisan kosong ketika SongManager memanggil GetSongsByUser() pada lapisan data tiruan tanpa kesalahan. Tidak perlu melakukan apa pun untuk panggilan ke metode AddSong() data tiruan, yang akan mengembalikan kesalahan nil secara default. Tes hanya memverifikasi bahwa memang tidak ada kesalahan yang dikembalikan dari panggilan parent ke metode SongManager AddSong().

package song_manager

import (
    "testing"
	. "abstract_data_layer"
	. "concrete_data_layer"
)

func TestAddSong_Success(t *testing.T) {
	u := User{Name:"Gigi", Email: "gg@gg.com"}
	mock := NewMockDataLayer()
	// Prepare mock responses
	mock.GetSongsByUserResponses = [][]Song{{}}

	lm, err := NewSongManager(u, &mock)
	if err != nil {
		t.Error("NewSongManager() returned 'nil'")
	}
    url := https://www.youtube.com/watch?v=MlW7T0SUH0E"
	err = lm.AddSong(Song{Url: url", Name: "Chacarron"}, nil)
	if err != nil {
		t.Error("AddSong() failed")
	}
}

$ go test
PASS
ok  	song_manager	0.006s

Kondisi kesalahan pengujian juga sangat mudah. Anda memiliki kontrol penuh pada apa yang mengembalikan lapisan data dari panggilan ke GetSongsByUser() dan AddSong(). Berikut ini adalah tes untuk memverifikasi bahwa ketika menambahkan duplikat lagu Anda mendapatkan pesan kesalahan yang benar kembali.

func TestAddSong_Duplicate(t *testing.T) {
    u := User{Name:"Gigi", Email: "gg@gg.com"}

	mock := NewMockDataLayer()
	// Prepare mock responses
	mock.GetSongsByUserResponses = [][]Song{{testSong}}

	lm, err := NewSongManager(u, &mock)
	if err != nil {
		t.Error("NewSongManager() returned 'nil'")
	}

	err = lm.AddSong(testSong, nil)
	if err == nil {
		t.Error("AddSong() should have failed")
	}

	if err.Error() != "Duplicate song" {
		t.Error("AddSong() wrong error: " + err.Error())
	}
}

Dua uji kasus berikut menguji bahwa pesan kesalahan yang benar dikembalikan ketika lapisan data itu sendiri gagal. Dalam kasus pertama, getSongsByUser() layer data mengembalikan error.

func TestAddSong_DataLayerFailure_1(t *testing.T) {
    u := User{Name:"Gigi", Email: "gg@gg.com"}

	mock := NewMockDataLayer()
	// Prepare mock responses
	mock.GetSongsByUserResponses = [][]Song{{}}
	e := errors.New("GetSongsByUser() failure")
	mock.Errors = []error{e}

	lm, err := NewSongManager(u, &mock)
	if err != nil {
		t.Error("NewSongManager() returned 'nil'")
	}

	err = lm.AddSong(testSong, nil)
	if err == nil {
		t.Error("AddSong() should have failed")
	}

	if err.Error() != "GetSongsByUser() failure" {
		t.Error("AddSong() wrong error: " + err.Error())
	}
}

Dalam kasus kedua, metode AddSong() layer data mengembalikan kesalahan. Karena panggilan pertama ke GetSongsByUser() harus berhasil, potongan mock.Errors berisi dua item: nil untuk panggilan pertama dan kesalahan untuk panggilan kedua.

func TestAddSong_DataLayerFailure_2(t *testing.T) {
    u := User{Name:"Gigi", Email: "gg@gg.com"}

	mock := NewMockDataLayer()
	// Prepare mock responses
	mock.GetSongsByUserResponses = [][]Song{{}}
	e := errors.New("AddSong() failure")
	mock.Errors = []error{nil, e}

	lm, err := NewSongManager(u, &mock)
	if err != nil {
		t.Error("NewSongManager() returned 'nil'")
	}

	err = lm.AddSong(testSong, nil)
	if err == nil {
		t.Error("AddSong() should have failed")
	}

	if err.Error() != "AddSong() failure" {
		t.Error("AddSong() wrong error: " + err.Error())
	}
}

Kesimpulan

Dalam tutorial ini, kami memperkenalkan konsep lapisan data abstrak. Kemudian, menggunakan domain pengelolaan musik pribadi, kami menunjukkan cara mendesain lapisan data, membuat lapisan data tiruan, dan menggunakan lapisan data tiruan untuk menguji aplikasi.

Di bagian dua, kami akan fokus pada pengujian menggunakan lapisan data nyata di-memori. Nantikan.