Pengujian unit dan ejekan

Question

Sepertinya ada banyak pertanyaan tentang "kapan harus mengejek". Namun sejauh ini saya tidak mendapatkan jawaban atas pertanyaan saya. Bisa jadi, saya tidak tahu permintaan pencarian khusus yang akan mengarahkan saya ke jawabannya.

Bayangkan kita memiliki kelas (MyClass). Bayangkan bahwa kelas ini memiliki metode yang dapat mengembalikan objek std :: string dan kelas pembungkus (MyStringWrapper ditentukan di pustaka lain). MyStringWrapper bukanlah agregator (kita dapat mempertimbangkan untuk menggunakan struct di sini, tetapi mari kita lebih memilih kelas untuk contoh khusus ini), karena penyetelnya memiliki satu jika dan beberapa operasi salin. Sekarang sudah ada kelas 3 (UserClass) yang menggunakan kelas MyClass dan MyStringWrapper.

Sebagai pengembang SW yang baik, saya ingin menguji unit UserClass saya (karena banyak yang merujuk "mencium kode"). Untuk pengujian unit, saya akan menggunakan gtests dan gmock untuk membuat tiruan dari MyClass (sebut saja MyClassMock). Namun, saya ingat bahwa di suatu tempat dikatakan "Anda harus mengejek semuanya, yang didefinisikan di perpustakaan lain / perpustakaan pihak ketiga". Baik std :: string dan MyStringWrapper ditentukan di pustaka pihak ketiga.

Sekarang pertanyaannya. Jadi, haruskah saya dalam hal ini membuat tiruan untuk std :: string dan MyStringWrapper?

Anda dapat membayangkan penggunaan objek std :: string / MyStringWrapper yang dikembalikan sebagai

if(myreturnedstdstring.empty())
  return 1;

if(mywrapperobject.failed())
  return 100;

Saya ditanya dalam komentar di sini Apakah ada gunanya pengujian unit yang menghentikan dan mengejek semua yang bersifat publik?

buat topik lain.

Answer 1

Apa pun di std :: adalah bagian dari bahasa dan tidak boleh diolok-olok. Pembungkus string Anda, jika bukan bagian dari "unit" yang diuji dapat diejek tetapi IMHO dan mengalami pembungkus seperti itu umumnya sangat ringan sehingga tiruan pada dasarnya akan mereproduksi kode. Dalam hal ini saya tidak akan mengejeknya. Namun jika pembungkusnya bisa berubah di masa mendatang, Anda harus memalsukannya jika Anda menginginkan pengujian unit yang stabil. Di sisi lain, pengujian gagal ketika perubahan yang tidak kompatibel dilakukan pada pembungkus akan bagus, tetapi lebih sulit untuk dilacak karena kesalahan akan terjadi di beberapa unit lain.

Answer 2

Saya ingat bahwa di suatu tempat dikatakan "Anda harus mengejek semuanya, yang didefinisikan di perpustakaan lain / perpustakaan pihak ketiga".

Itu mungkin nasihat pada satu waktu, tetapi bukan nasihat yang umum diberikan saat ini.

Saran saat ini adalah menggunakan tiruan secukupnya untuk membantu tujuan pengujian unit ini:

• Pengujian dapat dilakukan dengan cepat, paralel, atau dalam urutan apa pun dan kapan pun. Ini menyiratkan bahwa komponen yang berinteraksi dengan penyimpanan persisten (database, sistem file), koneksi lambat (jaringan) atau kondisi lingkungan yang tidak dapat Anda kendalikan dengan mudah (misalnya waktu) adalah kandidat untuk dipermainkan.
• Semua jalur melalui code-under-test dapat dilakukan. Jika respons (kesalahan) tertentu dari dependensi tidak dapat dengan mudah dipicu dengan kode sebenarnya, itu bisa menjadi alasan untuk meniru dependensi itu.

Jenis data sederhana, seperti string, MyStringWrapper, atau bahkan container tidak sesuai dengan poin tersebut, jadi tidak ada alasan untuk mengejeknya.