Tes parameter - Kapan dan mengapa Anda menggunakannya?


15

Baru-baru ini di tempat kerja kami memiliki beberapa perbedaan pendapat sehubungan dengan pengujian Parameter . Biasanya kami menggunakan gaya TDD (atau setidaknya mencoba) jadi saya mengerti manfaat dari approac itu. Namun, saya berjuang untuk melihat hasil pengujian parameterisasi. Sebagai referensi, kami bekerja pada layanan dan pustaka yang diekspos melalui antarmuka yang tenang.

Apa yang saya lihat sejauh ini adalah tes yang, setidaknya menggunakan JUnit di dalam Eclipse:

  • Kurang detail - ketika tes gagal, sangat sulit untuk melihat parameter yang menyebabkannya gagal
  • Seringkali rumit untuk dibuat
  • Cenderung dibuat setelah kode telah ditulis - benar-benar bukan kelemahan seperti itu tetapi apakah orang-orang berangkat dengan tes parameter dalam pikiran ketika mereka memulai sepotong kode?

Jika ada yang punya contoh di mana mereka benar-benar berguna atau bahkan ada petunjuk bagus untuk menggunakannya, itu akan fantastis. Saya ingin memastikan saya tidak hanya keras kepala karena saya pribadi tidak memilih untuk menggunakannya dan melihat apakah itu sesuatu yang harus kita pertimbangkan sebagai bagian dari gudang pengujian kami.


1
Masalahnya bukan dengan ide tetapi dengan perpustakaan yang kikuk. Dalam C # sintaksnya lebih ramah, ketika Anda menggunakan katakan MbUnit. Ya, itu ide yang bagus. Tambahkan kode Anda sendiri untuk membuat proses ini lebih mudah - baca barang dari file - apa pun yang berfungsi. Lihat juga bagaimana MsTest menangani ini.
Pekerjaan

Kami (Square) menulis Burst untuk mengatasi beberapa masalah ini dengan Parameterized. Ini umumnya menambahkan lebih sedikit boilerplate, dan membuatnya cukup jelas di mana tes gagal.
Daniel Lubarov

Jawaban:


4

Masalah dengan pengujian perangkat lunak apa pun adalah kompleksitasnya meledak dengan cepat. Faktanya adalah, Anda tidak dapat menguji semua kemungkinan kombinasi parameter yang diteruskan ke metode Anda. Phadke menganjurkan pendekatan Design of Experiments (DOE), yang memungkinkan pembuatan daftar kemungkinan nilai parameter yang perlu diuji.

Idenya adalah bahwa, meskipun Anda tidak menguji secara mendalam, sebagian besar cacat menyebabkan "daerah kesalahan" terjadi daripada kesalahan titik terisolasi. Pendekatan DOE yang didukung Phadke menggunakan array array ortogonal sampel ruang parameter cukup halus untuk memukul semua daerah kesalahan yang mungkin.

Kesalahan yang terisolasi mungkin tidak akan diidentifikasi, tetapi ini umumnya lebih sedikit dari daerah kesalahan.

Pendekatan DOE memberi Anda cara sistematis untuk memilih nilai parameter yang bervariasi.


Tautan yang diberikan rusak.
Josh Gust

1
@ JoshGust Mudah diperbaiki dengan menggunakan Google. Terimakasih atas peringatannya.
Peter K.

4

Mereka dapat berguna untuk memastikan bahwa kode Anda menangani tidak hanya jalan bahagia, tetapi juga tepi kasus. Setelah Anda tahu kode Anda berfungsi dengan variabel normal, parametrize kasus uji dan pastikan nol dan 0, string kosong, angka besar, string panjang, karakter Unicode aneh, dll., Juga berfungsi dengan baik.


2

Setidaknya ada dua jenis uji parameter, setidaknya di JUnit 4.8. Yaitu: Tes Parameter ( @RunWith(Parameterized.class)) yang membutuhkan sumber data, yang menghasilkan / membaca konfigurasi parameter yang telah ditentukan, dan Teori ( @RunWith(Theories.class)) yang, diberikan satu atau lebih set input yang mungkin per jenis argumen dapat menjalankan spesifikasi metode yang diberikan. Terlihat lebih seperti ini:

  • tentukan beberapa nilai yang mungkin ( @DataPoints) untuk argumen string (seperti null, string kosong, string tidak kosong, string sangat panjang)
  • tentukan beberapa nilai yang mungkin ( @DataPoints) untuk argumen kelas Animal (seperti null, Doginstance, Catinstance, Birdinstance)
  • siapkan @Theoryyang menerima Stringparameter dan Animalparameter. itu akan dieksekusi dengan setiap kombinasi yang mungkin dari nilai-nilai parameter yang mungkin (dalam contoh yang diberikan akan menjadi 4x4 = 16 kombinasi, termasuk ( null, null))
  • jika metode yang diuji tidak dapat menerima beberapa kombinasi, gunakan Assume.assumeThatimpor statis untuk memfilter kombinasi yang tidak valid (mis. ketika Anda ingin memeriksa perilaku metode untuk string yang tidak kosong, salah satu baris pertama adalah "anggap itu bukan nol"

Seperti yang ditulis sebelumnya - tidak masuk akal untuk menguji setiap kombinasi yang mungkin dari setiap metode (itu meledak set tes, bayangkan menguji suatu metode dengan 5 parameter, masing-masing hanya memiliki 5 nilai yang mungkin: 5 ** 5 -> lebih dari 3000 uji coba berjalan !), tetapi untuk metode mission-critical (seperti metode API) saya akan mendorongnya, hanya untuk berada di sisi yang aman ...


1

Contoh umum:

  • Metode dengan argumen string. Gunakan tes parametrized untuk menguji input berbeda dan output yang diharapkan. Jauh lebih praktis untuk memiliki daftar pasangan (input, diharapkan) daripada menulis TC untuk setiap pasangan.

  • Terapkan skenario yang sama pada berbagai argumen. Kami memiliki skenario yang bekerja dengan Animalobjek dan memiliki banyak subclass seperti Dog, Cat, Bird. Buat daftar hewan yang tersedia dan uji skenario pada mereka.

Beton untuk layanan web:

  • Dari argumen string contoh di atas. Uji apa yang terjadi dengan argumen berbeda dari tipe yang sama tetapi nilai yang berbeda.

0

Tes parameterisasi berfungsi dengan baik untuk menguji fungsi / fitur yang memiliki input sederhana ketika Anda ingin menguji berbagai input.

Mereka tidak bekerja dengan baik untuk menguji berbagai fungsi dan input kompleks. Mereka tidak boleh digunakan sebagai struktur kenyamanan untuk menulis lebih sedikit kode.


1
Mengapa parameter tidak boleh digunakan sebagai kemudahan untuk menulis lebih sedikit kode? Tidak ada kebajikan besar dalam memberikan daftar lengkap dari serangkaian besar (ish) kasus uji.
Jonathan Eunice

1
Bagaimana jawaban Anda memberikan lebih banyak informasi daripada 5 jawaban lainnya?
Adam Zuckerman

-2

Satu kasus di mana saya menggunakan banyak tes parameter dengan cara TDD-ish adalah menulis parser - Saya bisa mulai dengan daftar jika input dan output yang diharapkan dan kemudian menulis kode sehingga melewati semua kasus uji.

Tapi saya telah melihat beberapa kengerian pengujian parameter. Tidak, Virginia, ruang tes Anda seharusnya tidak memerlukan unit test sendiri.


1
Idealnya tes parametisasi harus dalam bentuk "apakah item (n) dalam item pencocokan output aktual (n) dalam output yang diharapkan" atau serupa, dan dalam hal itu tidak diperlukan pengujian. Tetapi untuk hal yang lebih kompleks, saya lebih suka melihat satu atau dua tes berparameter bersih dengan kasus uji mereka sendiri daripada handwaving biasa "(tes) kode saya jelas benar". Jika itu benar, Anda tidak akan menulis test case sama sekali. Jelas itu mungkin untuk pergi berlebihan dengan kompleksitas dan saya tidak berpendapat bahwa tidak ada garis, tapi saya pikir ada kasus di mana tes pengujian adalah ide yang bagus.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.