Apa yang Membuat Tes Unit Bagus? [Tutup]

97

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.

Spoike
sumber

Jawaban:

93

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.

Gishu
sumber
Kami mungkin tidak setuju tentang penggunaan Mocks, tetapi ini adalah artikel yang sangat bagus tentang praktik terbaik pengujian unit.
Justin Standard
Saya akan menemukan yang ini sebagai jawaban karena menurut saya akronim "A TRIP" berguna.
Spoike
3
Saya setuju untuk sebagian besar, tetapi ingin menunjukkan bahwa ada manfaat untuk menguji kode yang tidak Anda miliki ... Anda sedang menguji bahwa kode itu memenuhi persyaratan Anda. Bagaimana lagi Anda bisa yakin bahwa peningkatan tidak akan merusak sistem Anda? (Tapi tentu saja, perhatikan rasio biaya / manfaat saat melakukannya.)
Kecewa
@Craig - Saya yakin Anda mengacu pada tes regresi (tingkat antarmuka) (atau tes pelajar dalam beberapa kasus), yang mendokumentasikan perilaku yang Anda andalkan. Saya tidak akan menulis pengujian 'unit' untuk kode pihak ketiga karena a. vendor tahu lebih banyak tentang kode itu daripada saya b. Vendor tidak terikat untuk mempertahankan implementasi tertentu. Saya tidak mengontrol perubahan pada basis kode itu dan saya tidak ingin menghabiskan waktu saya untuk memperbaiki tes yang rusak dengan peningkatan. Jadi saya lebih suka membuat kode beberapa tes regresi tingkat tinggi untuk perilaku yang saya gunakan (dan ingin diberi tahu ketika rusak)
Gishu
@ Gishu: Ya, tentu saja! Pengujian hanya boleh dilakukan di tingkat antarmuka; dan nyatanya, Anda sebaiknya menguji fitur yang sebenarnya Anda gunakan. Selanjutnya, ketika memilih dengan apa menulis tes ini; Saya telah menemukan kerangka kerja pengujian 'unit' lurus ke depan yang sederhana biasanya sesuai dengan tagihan dengan sempurna.
Kecewa
42
  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.
Sören Kuklau
sumber
1
Jawaban yang bagus. Tapi tidak seburuk itu jika Anda tidak menguji unit untuk semua hal dalam pengiriman. Tentu itu lebih disukai, tetapi perlu ada keseimbangan dan pragmatisme. Re: mengajak kolega Anda bergabung; terkadang Anda hanya perlu melakukannya untuk menunjukkan nilai dan sebagai titik acuan.
Martin Clarke
1
Saya setuju. Namun, dalam jangka panjang, Anda harus dapat mengandalkan pengujian yang ada, yaitu dapat mengasumsikan bahwa kesalahan umum akan ditangkap olehnya. Jika tidak, manfaatnya akan berkurang secara drastis.
Sören Kuklau
2
"Jika Anda hanya menulis tes untuk beberapa kode Anda, itu hampir tidak berguna." Benarkah demikian? Saya punya proyek dengan cakupan kode 20% (area penting / rawan gagal) dan mereka membantu saya secara besar-besaran, dan proyek juga baik-baik saja.
dr. kejahatan
1
Saya setuju dengan Slough. Sekalipun hanya ada beberapa tes, mengingat mereka ditulis dengan baik dan cukup terisolasi, mereka akan sangat membantu.
Spoike
41

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.
womp
sumber
2
+1 karena point 1, 2 dan 5 itu penting. 3 dan 4 tampak agak berlebihan untuk pengujian unit, jika Anda sudah menggunakan nama metode pengujian deskriptif, tetapi saya merekomendasikan dokumentasi pengujian jika cakupannya besar (pengujian fungsional atau penerimaan).
Spoike
1 untuk pengetahuan dan contoh yang sederhana dan praktis
Phil
17

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

Mendelt
sumber
Saya kira maksud Anda Anda telah mengadaptasi dari buku "xUnit Test Patterns" oleh Gerard Meszaros. xunitpatterns.com
Spoike
Yup, kamu benar. Saya akan menjelaskannya di pos
Mendelt
Poin bagus. Pengujian unit bisa sangat berguna, tetapi sangat penting untuk menghindari terjebak dalam pengujian unit yang rumit dan saling bergantung yang menghasilkan pajak besar untuk setiap upaya mengubah sistem.
Wedge
9

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.

Haacked
sumber
9

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...
    }
}
Jay Bazuzi
sumber
Saya tidak setuju tentang hanya satu pernyataan per pengujian. Semakin banyak pernyataan yang Anda miliki dalam pengujian, semakin sedikit kasus uji potong dan tempel yang akan Anda miliki. Saya percaya kasus uji harus fokus pada skenario atau jalur kode dan pernyataan harus berasal dari semua asumsi dan persyaratan untuk memenuhi skenario itu.
Lucas B
Saya pikir kami setuju bahwa KERING berlaku untuk tes unit. Seperti yang saya katakan, "Tes unit harus difaktorkan dengan baik". Namun, ada beberapa cara untuk menyelesaikan duplikasi. Pertama, seperti yang Anda sebutkan, adalah memiliki pengujian unit yang pertama-tama memanggil kode yang sedang diuji, dan kemudian menegaskannya beberapa kali. Alternatifnya adalah membuat "perlengkapan uji" baru untuk skenario tersebut, yang memanggil kode yang diuji selama langkah Inisialisasi / Pengaturan, dan kemudian memiliki serangkaian pengujian unit yang hanya menegaskan.
Jay Bazuzi
Aturan praktis saya adalah, jika Anda menggunakan salin-tempel, Anda melakukan sesuatu yang salah. Salah satu ungkapan favorit saya adalah "Salin-tempel bukanlah pola desain." Saya juga setuju satu pernyataan per pengujian unit umumnya merupakan ide yang bagus, tetapi saya tidak selalu memaksakannya. Saya suka "uji satu hal per unit test" yang lebih umum. Meskipun itu biasanya diterjemahkan menjadi satu pernyataan per pengujian unit.
Jon Turner
7

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

Rob Wells
sumber
Rob - mekanik ini bagus, tapi meleset dari maksudnya. Kenapa kamu melakukan semua ini? Berpikir seperti ini dapat membantu orang lain menyusuri jalur TDD.
Mark Levison
7

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

Quibblesome
sumber
@Rismo Tidak eksklusif per se. Menurut definisi, apa yang ditulis Quarrelsome di sini eksklusif untuk metodologi "Uji Pertama", yang merupakan bagian dari TDD. TDD juga memperhitungkan refactoring. Definisi paling "smarty pants" yang pernah saya baca adalah bahwa TDD = Test First + Refactor.
Spoike
Ya itu tidak harus TDD, pastikan tes Anda gagal terlebih dahulu. Kemudian masukkan sisanya setelah itu. Hal ini paling sering terjadi saat melakukan TDD tetapi Anda juga dapat menerapkannya saat tidak menggunakan TDD.
Quibblesome
6

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.

Peter Evjan
sumber
6

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.

DanM
sumber
5

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 ..)
RoyOsherove
sumber
Roy, saya setuju sepenuh hati. Hal-hal ini jauh lebih penting daripada cakupan casing tepi.
Matt Hinze
layak dipercaya - poin bagus!
ratkok
4
  • 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.
Alotor
sumber
2

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

marcospereira.dll
sumber
1

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.

Joel di Gö
sumber
1

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/

akuhn
sumber
Saya setuju dengan anda TestNG adalah framework lain di mana dependensi diizinkan dengan mudah.
Davide
0

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.
VonC
sumber
0

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.

Techboy
sumber
Lalu bagaimana dengan unit testing?
Spoike
0

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.

Mengobrol
sumber