Apa yang Membuat Tes Unit Bagus? [Tutup]

Saya yakin sebagian besar dari Anda menulis banyak pengujian otomatis dan Anda juga telah mengalami beberapa kesalahan umum saat pengujian unit.

Pertanyaan saya adalah apakah Anda mengikuti aturan perilaku untuk tes menulis untuk menghindari masalah di masa depan? Untuk lebih spesifiknya: Apa sifat dari unit test yang baik atau bagaimana Anda menulis pengujian Anda?

Saran tanpa bahasa dianjurkan.

Izinkan saya mulai dengan memasukkan sumber - Pengujian Unit Pragmatis di Java dengan JUnit (Ada versi dengan C # -Nunit juga .. tapi saya punya yang ini .. sebagian besar agnostik. Direkomendasikan.)

Tes yang Baik haruslah PERJALANAN (Akronimnya tidak cukup lengket - Saya memiliki cetakan lembar contekan di buku yang harus saya tarik untuk memastikan saya melakukannya dengan benar ..)

• Otomatis : Menjalankan tes serta memeriksa hasil untuk LULUS / GAGAL harus otomatis
• Menyeluruh : Cakupan; Meskipun bug cenderung berkerumun di sekitar wilayah tertentu dalam kode, pastikan Anda menguji semua jalur dan skenario utama .. Gunakan alat jika Anda harus mengetahui wilayah yang belum diuji
• Dapat diulang : Tes harus menghasilkan hasil yang sama setiap saat .. setiap saat. Tes tidak harus bergantung pada parameter yang tidak terkendali.
• Independen : Sangat penting.
  • Tes harus menguji hanya satu hal pada satu waktu. Beberapa pernyataan diperbolehkan selama semuanya menguji satu fitur / perilaku. Saat tes gagal, itu harus menunjukkan lokasi masalah.
  • Tes tidak harus bergantung satu sama lain - Terisolasi. Tidak ada asumsi tentang urutan eksekusi pengujian. Pastikan 'bersihkan batu tulis' sebelum setiap pengujian dengan menggunakan pengaturan / pembongkaran dengan tepat

• Profesional : Dalam jangka panjang, Anda akan memiliki kode pengujian sebanyak produksi (jika tidak lebih), oleh karena itu ikuti standar desain yang baik yang sama untuk kode pengujian Anda. Kelas metode yang difaktorkan dengan baik dengan nama yang mengungkapkan niat, Tanpa duplikasi, pengujian dengan nama baik, dll.

• Tes yang bagus juga berjalan dengan Cepat . tes apa pun yang membutuhkan waktu lebih dari setengah detik untuk dijalankan .. perlu dikerjakan. Semakin lama rangkaian pengujian yang diperlukan untuk menjalankan .. semakin jarang pengujian akan dijalankan. Semakin banyak perubahan, dev akan mencoba menyelinap di antara lari .. jika ada yang rusak .. akan membutuhkan waktu lebih lama untuk mencari tahu perubahan mana yang menjadi penyebabnya.

Perbarui 2010-08:

• Dapat dibaca : Ini dapat dianggap sebagai bagian dari Profesional - namun tidak bisa cukup menekankan. Tes asam akan menemukan seseorang yang bukan bagian dari tim Anda dan memintanya untuk mengetahui perilaku yang diuji dalam beberapa menit. Pengujian perlu dipertahankan seperti halnya kode produksi - jadi buatlah agar mudah dibaca meskipun membutuhkan lebih banyak usaha. Pengujian harus simetris (mengikuti pola) dan ringkas (menguji satu perilaku pada satu waktu). Gunakan konvensi penamaan yang konsisten (misalnya gaya TestDox). Hindari mengacaukan ujian dengan "detail insidental" .. jadilah minimalis.

Selain itu, sebagian besar lainnya adalah pedoman yang mengurangi pekerjaan dengan manfaat rendah: misalnya 'Jangan menguji kode yang tidak Anda miliki' (misalnya DLL pihak ketiga). Jangan mencoba menguji pengambil dan penyetel. Perhatikan rasio biaya-ke-manfaat atau probabilitas kerusakan.

1. Jangan menulis tes yang luar biasa. Seperti yang disarankan oleh 'unit' dalam 'unit test', buatlah masing-masing sebagai atom dan terisolasi mungkin. Jika Anda harus, buat prasyarat menggunakan objek tiruan, daripada membuat ulang terlalu banyak lingkungan pengguna biasa secara manual.
2. Jangan menguji hal-hal yang jelas berhasil. Hindari menguji kelas dari vendor pihak ketiga, terutama yang memasok API inti dari kerangka kerja yang Anda kodekan. Misalnya, jangan menguji menambahkan item ke kelas Hashtable vendor.
3. Pertimbangkan untuk menggunakan alat cakupan kode seperti NCover untuk membantu menemukan kasus edge yang belum Anda uji.
4. Cobalah menulis tes sebelum penerapan. Anggap pengujian sebagai spesifikasi yang akan dipatuhi oleh penerapan Anda. Cf. juga pengembangan yang digerakkan oleh perilaku, cabang yang lebih spesifik dari pengembangan yang digerakkan oleh pengujian.
5. Bersikaplah konsisten. Jika Anda hanya menulis tes untuk beberapa kode Anda, itu hampir tidak berguna. Jika Anda bekerja dalam tim, dan beberapa atau semua orang lain tidak menulis tes, itu juga tidak terlalu berguna. Yakinkan diri Anda dan semua orang tentang pentingnya (dan properti hemat waktu ) pengujian, atau jangan repot-repot.

Sebagian besar jawaban di sini tampaknya membahas praktik terbaik pengujian unit secara umum (kapan, di mana, mengapa, dan apa), daripada benar-benar menulis pengujian itu sendiri (bagaimana). Karena pertanyaannya tampak cukup spesifik pada bagian "bagaimana", saya pikir saya akan memposting ini, diambil dari presentasi "tas coklat" yang saya lakukan di perusahaan saya.

5 Hukum Tes Menulis Womp:

1. Gunakan nama metode pengujian yang panjang dan deskriptif.

   - Map_DefaultConstructorShouldCreateEmptyGisMap()
   - ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
   - Dog_Object_Should_Eat_Homework_Object_When_Hungry()

2. Tulis tes Anda dalam gaya Atur / Bertindak / Tegaskan .

• Sementara strategi organisasi ini telah ada untuk beberapa waktu dan disebut banyak hal, pengenalan akronim "AAA" baru-baru ini telah menjadi cara yang bagus untuk menyampaikannya. Membuat semua pengujian Anda konsisten dengan gaya AAA membuatnya mudah dibaca dan dipelihara.

3. Selalu berikan pesan kegagalan dengan Asserts Anda.

Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element 
processing events was raised by the XElementSerializer");

• Praktik sederhana namun bermanfaat yang menjelaskan dalam aplikasi pelari Anda apa yang gagal. Jika Anda tidak memberikan pesan, biasanya Anda akan mendapatkan sesuatu seperti "Diharapkan benar, salah" dalam keluaran kegagalan Anda, yang membuat Anda harus benar-benar membaca tes untuk mencari tahu apa yang salah.

4. Komentari alasan pengujian - apa asumsi bisnisnya?

  /// A layer cannot be constructed with a null gisLayer, as every function 
  /// in the Layer class assumes that a valid gisLayer is present.
  [Test]
  public void ShouldNotAllowConstructionWithANullGisLayer()
  {
  }

• Ini mungkin tampak jelas, tetapi praktik ini akan melindungi integritas tes Anda dari orang-orang yang tidak memahami alasan di balik tes. Saya telah melihat banyak tes dihapus atau dimodifikasi yang baik-baik saja, hanya karena orang tersebut tidak memahami asumsi bahwa tes itu memverifikasi.
• Jika tesnya sepele atau nama metode cukup deskriptif, komentar tidak boleh dibiarkan.

5. Setiap pengujian harus selalu mengembalikan status sumber daya yang disentuhnya

• Gunakan tiruan jika memungkinkan untuk menghindari berurusan dengan sumber daya nyata.
• Pembersihan harus dilakukan di tingkat ujian. Tes tidak boleh bergantung pada urutan eksekusi.

Ingatlah tujuan ini (diadaptasi dari buku xUnit Test Patterns oleh Meszaros)

• Tes harus mengurangi risiko, bukan memperkenalkannya.
• Tes harus mudah dijalankan.
• Pengujian harus mudah dipelihara karena sistem berkembang di sekitarnya

Beberapa hal untuk mempermudah ini:

• Tes seharusnya hanya gagal karena satu alasan.
• Tes seharusnya hanya menguji satu hal
• Minimalkan ketergantungan pengujian (tidak ada ketergantungan pada database, file, ui, dll.)

Jangan lupa bahwa Anda juga dapat melakukan pengujian intergrasi dengan framework xUnit tetapi tetap pisahkan pengujian intergrasi dan pengujian unit

Tes harus diisolasi. Satu tes tidak harus bergantung pada yang lain. Lebih jauh lagi, pengujian seharusnya tidak bergantung pada sistem eksternal. Dengan kata lain, uji kode Anda , bukan kode yang bergantung pada kode. Anda dapat menguji interaksi tersebut sebagai bagian dari pengujian integrasi atau fungsional Anda.

Beberapa sifat pengujian unit yang bagus:

• Ketika sebuah tes gagal, harus segera terlihat jelas di mana letak masalahnya. Jika Anda harus menggunakan debugger untuk melacak masalah, pengujian Anda tidak cukup terperinci. Memiliki tepat satu pernyataan per pengujian membantu di sini.

• Saat Anda melakukan refaktorisasi, tidak ada pengujian yang gagal.

• Tes harus berjalan sangat cepat sehingga Anda tidak pernah ragu untuk menjalankannya.

• Semua tes harus selalu lulus; tidak ada hasil non-deterministik.

• Pengujian unit harus difaktorkan dengan baik, seperti kode produksi Anda.

@Alotor: Jika Anda menyarankan bahwa perpustakaan seharusnya hanya memiliki pengujian unit di API eksternalnya, saya tidak setuju. Saya ingin pengujian unit untuk setiap kelas, termasuk kelas yang tidak saya perlihatkan kepada penelepon eksternal. (Namun, jika saya merasa perlu menulis tes untuk metode privat, maka saya perlu melakukan refactor. )

EDIT: Ada komentar tentang duplikasi yang disebabkan oleh "satu pernyataan per pengujian". Secara khusus, jika Anda memiliki beberapa kode untuk menyiapkan skenario, dan kemudian ingin membuat beberapa pernyataan tentang hal itu, tetapi hanya memiliki satu pernyataan per pengujian, Anda dapat menduplikasi penyiapan di beberapa pengujian.

Saya tidak mengambil pendekatan itu. Sebagai gantinya, saya menggunakan perlengkapan uji per skenario . Berikut contoh kasarnya:

[TestFixture]
public class StackTests
{
    [TestFixture]
    public class EmptyTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
        }

        [TestMethod]
        [ExpectedException (typeof(Exception))]
        public void PopFails()
        {
            _stack.Pop();
        }

        [TestMethod]
        public void IsEmpty()
        {
            Assert(_stack.IsEmpty());
        }
    }

    [TestFixture]
    public class PushedOneTests
    {
        Stack<int> _stack;

        [TestSetup]
        public void TestSetup()
        {
            _stack = new Stack<int>();
            _stack.Push(7);
        }

        // Tests for one item on the stack...
    }
}

Apa yang Anda kejar adalah penggambaran perilaku kelas yang diuji.

1. Verifikasi perilaku yang diharapkan.
2. Verifikasi kasus kesalahan.
3. Cakupan semua jalur kode dalam kelas.
4. Menjalankan semua fungsi anggota di dalam kelas.

Maksud dasarnya adalah meningkatkan kepercayaan diri Anda terhadap perilaku kelas.

Ini sangat berguna saat melihat pemfaktoran ulang kode Anda. Martin Fowler memiliki artikel menarik tentang pengujian di situs webnya.

HTH.

Bersulang,

rampok

Tes seharusnya gagal. Kemudian Anda harus menulis kode yang membuatnya lulus, jika tidak, Anda berisiko menulis pengujian yang disadap dan selalu lolos.

Saya suka akronim Right BICEP dari buku Pragmatic Unit Testing yang disebutkan di atas :

• Benar : Apakah hasilnya benar ?
• B : Apakah semua b kondisi oundary benar?
• Saya : Bisakah kita periksa i nverse hubungan?
• C : Bisakah kita c hasil ross-cek menggunakan cara lain?
• E : Dapatkah kita memaksa e kondisi rror terjadi?
• P : Apakah p karakteristik erformance dalam batas-batas?

Secara pribadi saya merasa Anda bisa melangkah cukup jauh dengan memeriksa bahwa Anda mendapatkan hasil yang benar (1 + 1 harus mengembalikan 2 dalam fungsi penjumlahan), mencoba semua kondisi batas yang dapat Anda pikirkan (seperti menggunakan dua angka yang jumlahnya lebih besar dari nilai maks bilangan bulat dalam fungsi tambah) dan memaksa kondisi kesalahan seperti kegagalan jaringan.

Tes yang baik perlu dipertahankan.

Saya belum tahu bagaimana melakukan ini untuk lingkungan yang kompleks.

Semua buku teks mulai terlepas saat basis kode Anda mulai menjangkau ratusan 1000 atau jutaan baris kode.

• Interaksi tim meledak
• jumlah kasus uji meledak
• interaksi antar komponen meledak.
• waktu untuk membangun semua unit menjadi bagian penting dari waktu membangun
• perubahan API dapat memengaruhi ratusan kasus uji. Padahal perubahan kode produksi itu mudah.
• jumlah peristiwa yang diperlukan untuk mengurutkan proses ke dalam keadaan yang benar meningkat yang pada gilirannya meningkatkan waktu eksekusi uji.

Arsitektur yang baik dapat mengontrol beberapa ledakan interaksi, tetapi tak terelakkan ketika sistem menjadi lebih kompleks, sistem pengujian otomatis tumbuh bersamanya.

Di sinilah Anda mulai harus berurusan dengan trade-off:

• hanya menguji API eksternal jika tidak memfaktorkan kembali hasil internal dalam pengerjaan ulang kasus uji yang signifikan.
• penyiapan dan pembongkaran setiap pengujian menjadi lebih rumit karena subsistem yang dienkapsulasi mempertahankan lebih banyak status.
• kompilasi malam dan eksekusi uji otomatis bertambah menjadi berjam-jam.
• peningkatan waktu kompilasi dan eksekusi berarti desainer tidak atau tidak akan menjalankan semua pengujian
• untuk mengurangi waktu pelaksanaan pengujian, Anda mempertimbangkan pengujian pengurutan untuk mengurangi penyiapan dan pembongkaran

Anda juga perlu memutuskan:

di mana Anda menyimpan kasus uji di basis kode Anda?

• bagaimana Anda mendokumentasikan kasus uji Anda?
• dapatkah perlengkapan uji digunakan kembali untuk menghemat pemeliharaan kasus uji?
• apa yang terjadi jika eksekusi kasus uji malam gagal? Siapa yang melakukan triase?
• Bagaimana Anda mempertahankan objek tiruan? Jika Anda memiliki 20 modul yang semuanya menggunakan ragam API pembuatan log tiruannya sendiri, mengubah riak API dengan cepat. Tidak hanya kasus uji yang berubah tetapi 20 objek tiruan berubah. 20 modul tersebut ditulis selama beberapa tahun oleh banyak tim yang berbeda. Ini masalah penggunaan ulang klasik.
• individu dan timnya memahami nilai tes otomatis yang mereka tidak suka bagaimana tim lain melakukannya. :-)

Saya bisa bertahan selamanya, tetapi maksud saya adalah:

Tes harus dapat dipertahankan.

Saya membahas prinsip-prinsip ini beberapa waktu lalu di artikel Majalah MSDN ini yang menurut saya penting untuk dibaca oleh setiap pengembang.

Cara saya mendefinisikan pengujian unit yang "baik", adalah jika pengujian tersebut memiliki tiga properti berikut:

• Mereka dapat dibaca (penamaan, pernyataan, variabel, panjang, kompleksitas ..)
• Mereka Dapat Dipelihara (tanpa logika, tidak ditentukan secara berlebihan, berbasis negara bagian, difaktorisasi ulang ..)
• Mereka layak dipercaya (uji hal yang benar, terisolasi, bukan uji integrasi ..)

• Pengujian Unit hanya menguji API eksternal Unit Anda, Anda tidak boleh menguji perilaku internal.
• Setiap pengujian TestCase harus menguji satu (dan hanya satu) metode di dalam API ini.
  • Kasus Uji Tambahan harus disertakan untuk kasus kegagalan.
• Uji cakupan pengujian Anda: Setelah unit diuji, 100% baris di dalam unit ini seharusnya telah dieksekusi.

Jay Fields memiliki banyak nasihat bagus tentang menulis tes unit dan ada posting di mana dia merangkum nasihat paling penting . Di sana Anda akan membaca bahwa Anda harus memikirkan secara kritis konteks Anda dan menilai apakah nasihat itu berharga bagi Anda. Anda mendapatkan banyak jawaban luar biasa di sini, tetapi terserah Anda untuk memutuskan mana yang terbaik untuk konteks Anda. Cobalah dan lakukan refactoring jika baunya tidak enak bagi Anda.

Salam

Jangan pernah berasumsi bahwa metode 2 baris yang sepele akan berhasil. Menulis tes unit cepat adalah satu-satunya cara untuk mencegah tes nol yang hilang, tanda minus yang salah tempat dan / atau kesalahan pelingkupan halus dari menggigit Anda, pasti ketika Anda memiliki lebih sedikit waktu untuk menghadapinya daripada sekarang.

Saya mendukung jawaban "A TRIP", kecuali bahwa tes HARUS bergantung satu sama lain !!!

Mengapa?

KERING - Jangan Ulangi Dirimu - berlaku juga untuk pengujian! Uji ketergantungan dapat membantu untuk 1) menghemat waktu penyiapan, 2) menghemat sumber daya perlengkapan, dan 3) menunjukkan kegagalan. Tentu saja, hanya karena kerangka pengujian Anda mendukung dependensi kelas satu. Kalau tidak, saya akui, mereka buruk.

Tindak lanjuti http://www.iam.unibe.ch/~scg/Research/JExample/

Seringkali pengujian unit didasarkan pada objek tiruan atau data tiruan. Saya suka menulis tiga jenis tes unit:

• Pengujian unit "sementara": mereka membuat objek / data tiruan sendiri dan menguji fungsinya dengannya, tetapi menghancurkan semuanya dan tidak meninggalkan jejak (seperti tidak ada data dalam database pengujian)
• pengujian unit "persisten": mereka menguji fungsi dalam kode Anda membuat objek / data yang akan dibutuhkan oleh fungsi yang lebih maju di kemudian hari untuk pengujian unit mereka sendiri (menghindari fungsi lanjutan tersebut untuk membuat ulang setiap kali kumpulan objek / data tiruan mereka sendiri)
• Pengujian unit "berbasis persisten": pengujian unit menggunakan objek / data tiruan yang sudah ada (karena dibuat di sesi pengujian unit lain) oleh pengujian unit tetap.

Intinya adalah untuk menghindari memutar ulang semuanya agar dapat menguji setiap fungsi.

• Saya sangat sering menjalankan jenis ketiga karena semua objek / data tiruan sudah ada.
• Saya menjalankan jenis kedua setiap kali model saya berubah.
• Saya menjalankan yang pertama untuk memeriksa fungsi paling dasar sesekali, untuk memeriksa regresi dasar.

Pikirkan tentang 2 jenis pengujian dan perlakukan mereka secara berbeda - pengujian fungsional dan pengujian kinerja.

Gunakan masukan dan metrik yang berbeda untuk masing-masing. Anda mungkin perlu menggunakan perangkat lunak yang berbeda untuk setiap jenis tes.

Saya menggunakan konvensi penamaan pengujian yang konsisten yang dijelaskan oleh standar Penamaan Uji Unit Roy Osherove Setiap metode dalam kelas kasus uji yang diberikan memiliki gaya penamaan berikut MethodUnderTest_Scenario_ExpectedResult.

Bagian nama pengujian pertama adalah nama metode dalam sistem yang diuji.

Berikutnya adalah skenario spesifik yang sedang diuji.

Terakhir adalah hasil dari skenario itu.

Setiap bagian menggunakan Casing Unta Atas dan dibatasi oleh skor di bawah.

Saya menemukan ini berguna ketika saya menjalankan tes tes dikelompokkan berdasarkan nama metode yang diuji. Dan memiliki konvensi memungkinkan pengembang lain untuk memahami maksud pengujian.

Saya juga menambahkan parameter ke nama Metode jika metode yang diuji telah kelebihan beban.