Nunit: Atribut Ketergantungan Uji

Bug ini menggandakan dan menggantikan https://bugs.launchpad.net/nunit-3.0/+bug/740539 yang memiliki beberapa diskusi.

Sementara ketergantungan dan pengurutan tidak identik, mereka terkait dalam pengurutan tes adalah salah satu cara untuk memodelkan ketergantungan. Namun, hal lain dapat memengaruhi pemesanan, seperti tingkat kepentingan tes. Bagaimanapun, kedua masalah itu harus diselesaikan bersama.

Saya sangat menyukai model MbUnit:

• Ketergantungan pada rangkaian pengujian lain: pengujian anotasi (atau perlengkapan pengujian) dengan [DependsOn(typeof(AnotherFixtureType))]
• Ketergantungan pada tes lain: tes anotasi dengan [DependsOn("TestInThisFixture")]

Apa yang dilakukan MbUnit jika Anda mengatur "ketergantungan" siklik?

Pada Minggu, 3 November 2013 pukul 12:25, ashes999 [email protected] menulis:

Saya sangat menyukai model MbUnit:

• Ketergantungan pada rangkaian pengujian lain: uji anotasi (atau perlengkapan uji)
  dengan [DependsOn(typeof(AnotherFixtureType))]
• Ketergantungan pada tes lain: tes anotasi dengan
  [DependsOn("TestInThisFixture")]

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/nunit/nunit-framework/issues/51#issuecomment -27653262
.

@CharliePoole jika Anda membuat siklus atau menentukan ketergantungan metode pengujian yang tidak ada, MbUnit melempar pengecualian runtime. Karena bergantung pada kelas memerlukan tipenya, itu akan serupa (tergantung pada non-tes) atau kesalahan waktu kompilasi (tipe itu tidak ada).

Setiap pembaruan tentang masalah ini? Saya memilih MbUnit karena pemesanan. Sekarang dalam jeda yang tidak terbatas, saya perlu mencari alternatif. Alangkah baiknya jika NUnit dapat mendukung fitur penting ini dalam pengujian integrasi.

Maaf, belum ada pembaruan, meskipun saya juga berasal dari MbUnit dan menggunakan ini untuk beberapa tes integrasi kami. Jika Anda hanya ingin memesan tes dalam kelas tes, NUnit akan menjalankan tes dalam urutan abjad dalam perlengkapan tes. Ini tidak didukung dan tidak didokumentasikan, tetapi berfungsi sampai kami memiliki alternatif.

Saya pikir ini akan datang di v3?

Ya, tapi sampai sekarang belum dikerjakan. Setelah alpha 3.0 pertama, kita akan
menambahkan fitur lebih lanjut.
Pada 13 Juni 2014 20:28, "fraser addison" [email protected] menulis:

Saya pikir ini akan datang di v3?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/nunit/nunit-framework/issues/51#issuecomment -46044623
.

Untuk 3.0, kami akan menerapkan atribut pesanan pengujian, bukan atribut ketergantungan seperti MbUnit. Lihat edisi #170

Lihat komentar saya di #170. Pemesanan sangat terbatas dan rentan terhadap pemeliharaan (kecuali jika Anda menggunakan kelipatan sepuluh sehingga Anda dapat menyisipkan tes di tengah tanpa menyusun ulang semuanya). MbUnit memiliki grafik ketergantungan arbitrer, yang saya (atau mungkin saya harus mengatakan "kami" karena saya bukan satu-satunya) benar-benar membutuhkan.

Tergantung pada urutan abjad adalah penopang, dan yang cukup lemah mengingat ini bisa berubah kapan saja.

Hai,

Pada Kamis, 7 Agustus 2014 pukul 06:10, Ashiq [email protected] menulis:

Lihat komentar saya di #170. Pemesanan sangat terbatas dan rentan terhadap pemeliharaan (kecuali jika Anda menggunakan kelipatan sepuluh sehingga Anda dapat menyisipkan tes di tengah tanpa menyusun ulang semuanya). MbUnit memiliki grafik ketergantungan arbitrer, yang saya (atau mungkin saya harus mengatakan "kami" karena saya bukan satu-satunya) benar-benar membutuhkan.

Ya. Gagasan untuk menggunakan pemesanan didasarkan pada asumsi yang tidak dinyatakan: bahwa
itu hampir tidak akan digunakan sama sekali. Mencoba mengontrol urutan runtime dari
semua tes Anda adalah ide yang sangat buruk. Namun, dalam kasus _jarang_, mungkin
diinginkan untuk memastikan beberapa uji berjalan terlebih dahulu. Untuk penggunaan terbatas seperti itu,
pemesanan bilangan bulat baik-baik saja dan kesulitan memasukkan item baru ke dalam
perintah itu mungkin berfungsi sebagai keputusasaan untuk yang tidak perlu
memesan tes.

Perhatikan bahwa masalah ini berkaitan dengan urutan metode Uji, bukan
perlengkapan tes. Masalah #170 berlaku untuk perlengkapan uji dan bukan metode sebagai
ditulis, karena menggunakan Type sebagai item dependen. Yang mengatakan,
contoh di #170 tampaknya menyiratkan bahwa pemesanan metode diinginkan.

Pada dasarnya, kami memutuskan bahwa #170 membutuhkan terlalu banyak pekerjaan desain untuk
termasuk dalam rilis 3.0 tanpa menunda lebih lanjut. Kami terpilih -
dalam kasus ini dan lainnya - untuk membatasi fitur baru demi lebih cepat
melepaskan. Menetapkan #170 ke tonggak "Masa Depan" tidak berarti itu
tidak akan terjadi. Kemungkinan besar kami akan membahasnya dalam rilis poin.

Penggunaan OrderAttribute dipandang sebagai cara cepat memberi
"sesuatu" bagi mereka yang ingin mengontrol urutan metode pengujian
eksekusi. Kami merasa kami bisa mendapatkannya dengan cepat. Bahkan, kita mungkin memiliki
telah salah. Memikirkannya lebih jauh, saya dapat melihat bahwa itu dapat memperkenalkan
kemampuan yang sulit dipertahankan dalam menghadapi paralel
eksekusi tes. Faktanya, pendekatan ketergantungan umum mungkin adalah apa yang kita
membutuhkan. Untuk saat ini, saya memindahkan kedua masalah dari tonggak 3.0
sampai kita bisa melihat mereka lebih jauh.

Tergantung pada urutan abjad adalah penopang, dan yang cukup lemah mengingat ini bisa berubah kapan saja.

Memang. Kami selalu menyarankan orang untuk tidak menggunakannya untuk hal itu
alasan. Faktanya, itu tidak dijamin di NUnit 3.0.

Charlie

Saya belum pernah menggunakan MbUnit selama bertahun-tahun tetapi ingin menambahkan diskusi ini jika ingatan saya benar.

Dengan asumsi [Uji Z] tergantung pada [Uji A]. Saya kemudian menjalankan [Uji Z]. Tampaknya NUnit mengevaluasi hasil [Uji A] terlebih dahulu. Jika tidak ada hasil yang tersedia maka NUnit akan secara otomatis menjalankan [Uji A] sebelum mencoba menjalankan [Uji Z] yang diminta. NUnit hanya akan menjalankan [Uji Z] jika [Uji A] lulus. Jika tidak, [Uji Z] akan ditandai sebagai tidak meyakinkan dan menunjukkan ketergantungannya pada [Uji A] yang gagal.

Ini mungkin memberikan beberapa wawasan:
https://code.google.com/p/mb-unit/source/browse/trunk/v3/src/MbUnit/MbUnit/Framework/DependsOnAssemblyAttribute.cs?spec=svn3066&r=1570

https://code.google.com/p/mb-unit/source/browse/trunk/v3/src/MbUnit/MbUnit/Framework/DependsOnAssemblyAttribute.cs?r=1570

@circa1741 : Kami akan mengerjakan ini di "masa depan" yang saya maksud adalah rilis setelah 3.0. Ketergantungan penuh benar-benar merupakan hal yang cukup rumit untuk diterapkan dan kami sudah mengambil banyak di 3.0.

Memesan tes adalah bandaid jika yang Anda inginkan adalah ketergantungan yang sebenarnya, tetapi cukup mudah untuk diterapkan.

Dengan melakukan pemesanan (#170) di 3.0 kami menjalankan risiko: beberapa pengguna akan memperlakukannya sebagai jawaban untuk masalah ketergantungan mereka dan bergantung padanya dalam konteks yang salah. Namun, tampaknya lebih baik daripada tidak melakukan apa-apa.

Saya ingin mencari waktu untuk menulis artikel tentang berbagai jenis ketergantungan dan pemesanan dan bagaimana perbedaannya dalam penggunaan dan implementasi... mungkin... ;-)

Koreksi: setelah saya menulis komentar sebelumnya, saya perhatikan bahwa #170 juga dijadwalkan untuk 'masa depan'.

Kami akan terus mendiskusikan apakah mungkin untuk menyertakan beberapa fitur pemesanan di 3.0 sebagai lawan dari 3.2, tetapi saat ini tidak direncanakan.

(Contoh diambil dari http://blog.bits-in-motion.com/search?q=mbunit)

Saat menulis tes integrasi, terkadang berguna untuk menyatukan beberapa tes yang menangkap urutan operasi yang logis.

MbUnit dapat menangkap rantai ini baik dengan dependensi:

Juga memungkinkan [DependsOn(typeof(ClassName.MethodName))]]

Atau dengan pemesanan eksplisit:

Terima kasih untuk contoh kodenya. Ini memberikan sesuatu untuk dituju. Contoh pertama Anda relevan dengan masalah ini. Yang kedua adalah persis apa yang kami rencanakan untuk #170.

Saya punya ide yang lebih merupakan twist untuk ketergantungan dan pemesanan.

Diskusi, sejauh ini, mengenai ketergantungan adalah "lanjutkan dan jalankan Tes H (dan mungkin 8 tes lainnya) hanya jika Tes 8 lulus." Dengan kata lain, tidak ada gunanya menjalankan Tes H karena jika Tes 8 gagal maka saya tahu bahwa Tes H juga akan gagal.

Bagaimana dengan ketergantungan ketika tes gagal?

Skenario:
Saya membutuhkan Tes Asap yang mencakup banyak tanah. Jadi, saya merencanakan Test Fixture yang merupakan tes ujung ke ujung yang memiliki cakupan dasar dari banyak fitur SUT. Tes pada perlengkapan tes tersebut akan menggunakan Pengurutan Tes dan "tidak independen." Urutan tesnya adalah Tes A lalu Tes B lalu Tes C, dll.

Sekarang, karena tesnya "tidak independen", saya tahu bahwa jika Tes C gagal maka semua tes berikut juga akan gagal. Oleh karena itu, saya membutuhkan lebih banyak tes untuk dijalankan untuk mendapatkan gambaran yang lebih besar tentang Tes Asap.

Saya harus dapat mengonfigurasi untuk menjalankan Tes 1 jika Tes A gagal, Tes 2 jika Tes B gagal, Tes 3 jika Tes C gagal, dll.

Tes 3 saya dirancang untuk tidak bergantung pada Tes B jadi jika ini gagal maka saya memiliki pemahaman yang lebih baik tentang mengapa Tes C gagal sebelumnya. Ternyata Tes saya 4 (untuk Tes D), 5 (untuk E), 5 (untuk F), dll semua lulus. Kemudian saya sekarang mengerti bahwa hanya fitur yang dicakup oleh Tes C yang menjadi masalah.

Mengapa tidak menjalankan Tes 1, 2, 3, dll.? Nah, karena itu adalah tes yang terisolasi dan independen maka saya tidak melakukan Tes Integrasi. Sekali lagi, saya membutuhkan Tes Asap yang mencakup banyak tanah.

Mungkin sesuatu seperti:

• [DependsOnPassing("Uji ini dan itu")]
• [DependsOnFailing("Uji bla bla bla")]

Ini akan memungkinkan kontrol yang lebih baik dalam desain pengujian otomatisasi saya.

Bagaimana dengan sesuatu seperti atribut ini sebagai gantinya:

• [DependsOnPassing("Uji ini dan itu")]
• [RunOnFail("Uji bla bla bla")]

Harap perhatikan tes mana yang dilampirkan. Atribut-atribut ini harus dapat digunakan di tingkat yang berbeda (dan dalam segala hal): perakitan, perlengkapan uji, pengujian.

[DependsOnPassing("Uji E")]
Uji F

• Tes E akan otomatis dijalankan jika hasilnya tidak diketahui.
• Hanya dengan begitu Tes F akan ditentukan apakah harus dijalankan atau tidak.

[RunOnFail("Uji N")]
Tes I

• Jika Tes I gagal maka Tes N akan otomatis dijalankan.

Tes N

• Tes N dapat dijalankan sendiri.
• Tapi itu juga akan otomatis dijalankan jika Tes I gagal.

Tes E

• Tes E dapat dijalankan sendiri.
• Tetapi juga akan otomatis dijalankan jika hasilnya tidak diketahui karena Tes F bergantung pada kelulusan tes ini terlebih dahulu.

Disalin dari #1031, yang jelas-jelas menduplikasi ini. Semoga contohnya membantu dan kata kunci mengarahkan orang lain ke sini ...

Saya memiliki beberapa kasus di mana saya ingin menandai tes sebagai prasyarat tes lain. Akan lebih baik untuk memiliki atribut yang menunjukkan tes yang merupakan prasyarat dari tes saat ini.

Dalam kasus di mana rutinitas bergantung satu sama lain, adalah mungkin untuk mengetahui bahwa tes yang diberikan akan gagal karena sub-rutin gagal dalam pengujiannya. Jika tes berjalan lama, sebenarnya tidak ada gunanya menjalankan tes jika sub-rutin tetap rusak.

Contoh Buatan:

public static class Statistics
{
    public static double Average(IEnumerable<double> values)
    {
        double sum = 0;
        double count = 0;
        foreach (var v in values)
        {
            sum += v;
            count++;
        }
        return sum / count;
    }

    public static double MeanVariance(IEnumerable<double> values)
    {
        var avg = Average(values);
        var variance = new List<double>();
        foreach (var v in values)
        {
            variance.Add(Math.Abs(avg - v));
        }
        avg = Average(variance);
        return avg;
    }
}

[TestFixture]
public class TestStatistics
{
    [Test]
    public void Average()
    {
        var list = new List<double> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
        var avg = Statistics.Average(list);
        Assert.AreEqual(4.5, avg);
    }

    [Test]
    //[Prerequisite("TestStatistics.Average")]
    public void MeanVariance()
    {
        //try { this.Average(); } catch { Assert.Ignore("Pre-requisite test 'Average' failed."); }
        var list = new List<double> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
        var variance = Statistics.MeanVariance(list);
        Assert.AreEqual(0, variance);
    }
}

Diberikan contoh, jika pengujian Average gagal, masuk akal untuk tidak repot menguji MeanVariance .

Saya akan membayangkan ini bekerja dengan merantai tes:

• jika MeanVariance dijalankan, Average dipaksa untuk dijalankan terlebih dahulu.
• Jika Average telah dijalankan, hasilnya dapat digunakan kembali.
• Jika Average gagal, MeanVariance akan dilewati.

Apakah ada ketentuan tentang kapan fitur ini akan tersedia? Saya belum menemukan informasi ini di utas lain, mungkin ini adalah pertanyaan rangkap.

Itu ada di tonggak 'Masa Depan', itu berarti setelah 3.2, yang merupakan tonggak aktual terbaru yang kita miliki. Namun, kami akan mengalokasikan kembali masalah ke pencapaian, jadi perhatikan perubahannya.

Dengan semangat memperluas NUnit untuk memenuhi kebutuhan pengujian selain hanya pengujian unit, saya akan membahas percakapan ini. Percakapan sejauh ini merupakan langkah ke arah yang benar, tetapi saya merasa ada aspek kunci yang hilang.

Tes unit secara inheren datar (yaitu setup, menjalankan satu tes, teardown), dan tidak boleh memiliki ketergantungan pada tes lain yang telah dijalankan. Pengujian integrasi menambahkan ide pengujian berurutan (atau pengujian dependen untuk beberapa definisi dependen) yang mengatakan bahwa pengaturan terhubung ke sistem, pengujian A membuat beberapa objek, pengujian B memodifikasi objek yang dibuat oleh A, pengujian C menghapus objek yang dibuat oleh A, dan tear-down terputus dari sistem. Contoh terakhir ini tampaknya menjadi apa yang kebanyakan orang bicarakan di utas ini.

Pertimbangkan pengujian UI situs web, kami memiliki halaman yang dapat menavigasi ke beberapa halaman lain, dan beberapa tindakan dapat dilakukan pada halaman itu, yang dapat memengaruhi penggunaan halaman lain. Dalam struktur pengujian unit, saya perlu menavigasi ke halaman A, buat objek A.1, navigasikan ke halaman B buat objek B.1. Itu salah satu tes, yang mengimplementasikan ulang tes membuat objek A.1 (dari halaman yang berbeda). Sekarang pertimbangkan saya memerlukan tes yang memodifikasi B.1 untuk menunjuk ke A.1, saya harus mengulang semua yang baru saja saya lakukan untuk menulis tes ini. Jika kita memodifikasi contoh ini agar sesuai dengan analogi tes integrasi, saya harus melakukan sedikit lebih sedikit pekerjaan untuk langkah terakhir, karena saya dapat mengandalkan B.1 berada di kelas yang sama dan dengan demikian dapat melakukan semacam [DependsOn("Create_B1_Object")] atribut; namun, jika semua pengujian untuk halaman A berada di kelas yang terpisah, bagaimana saya bisa menautkan keduanya?

Intinya di sini adalah bahwa pengujian UI sering kali melibatkan semacam struktur pohon untuk rangkaian pengujian Anda. Semua tes anak di bawah simpul B mengharuskan B selesai dengan sukses, dan B bergantung pada simpul A yang berhasil diselesaikan, tetapi tetangga ke B tidak bergantung pada B yang dijalankan sama sekali. Struktur pohon memungkinkan Anda menguji semua fungsionalitas halaman A secara independen dari hal lain, tetapi karena tata letak dan objek yang tersedia di halaman B bergantung pada beberapa fungsionalitas halaman A, itu dapat bergantung pada semua tindakan yang telah dilakukan (melalui PageATests.CreateObject_A1 telah dijalankan sebagai induk).

Dalam struktur pohon, tidak ada yang berarti Anda tidak dapat memiliki pengujian datar (unit), atau pengujian (integrasi) yang dipesan, Anda dapat memiliki yang terbaik dari semuanya, tetapi Anda menambahkan kemampuan untuk melakukan pengujian UI.

Hanya $0,02 saya untuk apa nilainya

Persis pikiran saya. Anda ingin serangkaian tes yang masing-masing tes mungkin memiliki ketergantungan pada yang lain. Seri mungkin atau mungkin tidak memiliki ketergantungan satu sama lain. Kurang lebih apa yang saat ini dimungkinkan dengan Tes yang Dipesan MSTest, selain itu MSTest juga memungkinkan kelanjutan tes bahkan jika terjadi kegagalan.

Contoh sempurna adalah pengujian UI yang sering (selalu?) peka terhadap urutan dan konteks.

Selain MSTest, tidak ada kerangka pengujian yang dikembangkan secara aktif yang memungkinkan pengembangan jenis pengujian semacam itu.

@fgsahoward Saya sepenuhnya setuju dengan Anda setidaknya pada tingkat tinggi - seperti yang ditunjukkan oleh pembacaan yang cermat dari diskusi sebelumnya.

Saya katakan "hati-hati" karena saya tidak setuju dengan banyak detail spesifik dari proposal yang telah dibuat. Seperti yang Anda lihat, sekarang terdaftar sebagai fitur di backlog kami. Dalam pandangan saya, kita harus berhati-hati saat menerapkannya karena dua alasan utama:

1. Fitur ini sering diminta oleh orang yang menulis tes unit.
2. Beberapa orang (biasanya orang yang sama) mengartikan sesuatu yang berbeda dengan ketergantungan daripada yang Anda lakukan.

Saya umumnya berpendapat bahwa urutan pengujian yang sebenarnya, sebagai serangkaian langkah, sangat penting untuk berbagai jenis pengujian, termasuk yang Anda sebutkan. Saya pikir kita perlu membuatnya tersedia dengan cara tertentu, yang meminimalkan kemungkinan orang akan menggunakannya untuk tujuan lain. Itu mungkin berarti atribut berbeda yang digunakan untuk membubuhi keterangan kelas atau namespace yang mewakili pengujian keseluruhan serta atribut lain (berbeda) yang menjelaskan langkah-langkah dalam pengujian itu.

IOW, saya tidak ingin menempelkan fitur ini di atas TestFixture dan Test.

Masalah kedua mungkin perlu ditangani oleh semacam atribut ketergantungan, mungkin termasuk indikasi "kekuatan" relatif dari ketergantungan. IOW, jika yang Anda maksud dengan dependensi adalah "Buang-buang waktu menjalankan B jika A gagal, karena pasti akan gagal" maka menjalankan tes B atau tidak bisa pada opsi framework.

Sebenarnya, apa yang Anda jelaskan adalah apa yang saya sebut memesan. Memesan bisa lebih ketat daripada ketergantungan. Sebagai pengembang gui (fokus utama saya selama bertahun-tahun) saya tidak ingin menentukan dependensi dan meminta kerangka kerja untuk mengetahui urutannya. Saya ingin menentukan pemesanan secara eksplisit.

Cara lain yang telah saya bicarakan sebelumnya adalah dengan menyebut apa yang Anda bicarakan sebagai "ketergantungan ketat" dan jenis lainnya "ketergantungan tidak langsung". Itu ternyata tidak terlalu jelas bagi kebanyakan orang. Mungkin ketika kami membuat beberapa implementasi pengujian, itu akan menjadi lebih jelas. :-)

@Sebazzz Terima kasih atas tip tentang MsTest Saya mungkin melihat apakah kita dapat membuatnya sesuai dengan kebutuhan kita dalam beberapa mode sampai fitur ini dikembangkan.

@CharliePoole Saya sepenuhnya setuju, perlu ada perbedaan yang sangat jelas antara jenis tes yang akan Anda mulai tulis. Saya tidak ingin semua fitur yang berbeda ini digabungkan menjadi satu atribut dengan konfigurasi yang berbeda. Saya kurang lebih menyarankan bahwa implementasi yang mendasarinya dapat menggunakan struktur pohon untuk semua jenis tes, atribut hanya menentukan pemesanan dan dependensi.

Saya pikir sangat jelas bahwa tidak ada yang ingin mengacaukan garis antara gaya pengujian yang berbeda, sehingga Anda tidak berakhir dengan peretasan gaya pengujian yang digunakan untuk pengujian unit. Terima kasih atas catatan Anda, dan saya menantikan solusi yang Anda semua dapatkan di masa mendatang. :)

@oznetmaster Melanjutkan diskusi dari #170...

Kami telah memperpanjang diskusi tentang daftar nunit di masa lalu tentang apa arti ketergantungan. Komentar Anda akan cocok di sana dan menggambarkan apa yang sering saya sebut "ketergantungan yang ketat".

Masalahnya adalah bahwa kami didorong oleh pengguna dan pengguna yang meminta ketergantungan sering kali berarti sesuatu yang kurang tepat daripada yang Anda gambarkan. Saya melakukan analisis sekali dan menghasilkan tiga definisi utama ketergantungan. Seperti banyak tulisan saya sebelumnya, itu tersesat dalam memindahkan proyek dari satu tempat ke tempat lain, tetapi jika kita semakin dekat untuk mengimplementasikan sesuatu, saya harus mencoba memulihkannya.

Pada dasarnya - dan mungkin terlalu sederhana - saya menemukan bahwa orang yang mengatakan Tes B bergantung pada Tes A berarti salah satu dari tiga hal:

1. Tes A menetapkan prasyarat yang diperlukan agar Tes B berjalan atau berhasil.
2. Jika tes A gagal, maka tes B akan gagal, jadi tidak perlu dijalankan. (berbeda dari 1 karena korelasinya bukan kausalitas, tetapi karena kedua pengujian membutuhkan fitur yang sama agar dapat bekerja.)
3. Jika tes A gagal, hanya itu yang perlu kita ketahui - tes B tidak akan memberikan informasi yang berguna.

Perbedaan utama dengan tipe 2 dan 3 adalah bahwa kerangka kerja dapat memilih untuk tetap menjalankannya jika itu lebih nyaman. Dengan tipe 1, kerangka kerja tidak boleh menjalankan Tes B.

Ketergantungan jika terjadi kegagalan daripada kesuksesan adalah ekstensi yang bagus.

Ketika kami melakukan diskusi ini, setiap orang dengan pandangan berpikir bahwa pandangan itu adalah definisi "" ketergantungan dan orang lain harus menggunakan kata yang berbeda. :-) Saya kurang peduli dengan mengetahui definisi yang tepat daripada memberikan setiap kelompok apa yang mereka minta.

Saya sepenuhnya setuju dengan semua itu.

Namun TestB berjalan setelah TestA hanya menetapkan urutan, persis seperti jika TestA memiliki urutan 1 dan TestB memiliki urutan 2. Tidak ada ketergantungan tersirat lainnya dalam dua tes. TestB akan berjalan independen dari TestA berhasil atau gagal, dan tidak ada asumsi implisit bahwa TestA "menyiapkan" TestB.. Ini berbeda dari tiga kasus yang Anda daftarkan. Inilah sebabnya mengapa ini benar-benar semantik pemesanan, bukan ketergantungan. Ini persis sama dengan menggunakan ordinal untuk memesan, tetapi jauh lebih intuitif dan lebih mudah untuk dipelihara dan didokumentasikan sendiri.

"TestB berjalan setelah TestA" tidak jelas. Setelah TestA dimulai? selesai? berhasil?

Namun, saya mengerti apa yang Anda katakan. Dimungkinkan untuk menggunakan sintaks ketergantungan yang hanya diterjemahkan ke dalam jenis pemesanan yang kita lakukan. Saya kira itu bisa menjadi arti keempat dari "tergantung" jika kita ingin pergi ke sana.

Apakah Anda menyarankan kami mengubah apa yang kami lakukan dalam PR ini? Atau melakukan sesuatu yang lain di masa depan?

@oznetmaster Pada akhirnya kita mungkin akan memiliki maksimal satu "OrderAttribute" (atau serupa) dan satu "DependsOnAttribute." Kita harus memilih arti yang jelas untuk masing-masing arti (jika kita memiliki keduanya) atau menyediakan semacam properti yang memungkinkan pengguna untuk memilih dari beberapa arti. Apakah Anda setuju?

Tampaknya masuk akal bagi saya. Jika kita menggunakan pohon ketergantungan untuk semuanya, maka satu atribut akan berfungsi, dengan kondisi berbeda untuk arti ketergantungannya.

Tampaknya urutan ordinal sama ambigunya. Apa artinya memesan 1, 2, 3, sebenarnya. Apakah mereka mulai dalam urutan itu? Apakah mereka menunggu yang sebelumnya selesai sebelum memulai?

Saya pikir PR ini bisa melakukan semuanya. Pemesanan dan ketergantungan memerlukan pembuatan pohon ketergantungan logis. Itu adalah langkah pertama.

Apa yang dilakukan dengan pohon itu bisa dua PR, atau satu ini. Saya tahu Anda menyukai PR yang lebih kecil, tetapi saya tidak memiliki pemahaman yang baik tentang seberapa besar melakukan semuanya dalam satu PR.

Masalah ketergantungan lintas TestFixture (atau ketergantungan TestFixture) juga ikut berperan, seperti halnya dependensi perakitan uji silang. Saya tidak menyarankan kita melakukan semuanya, tetapi setidaknya kita harus mempertimbangkannya. Ini berlaku untuk pemesanan sederhana juga.

Kecuali ini bukan PR. Bukan hanya pertengkaran semantik: tidak ada pekerjaan yang dilakukan untuk itu, bahkan tidak dijadwalkan atau ditugaskan. OTOH, yang lain adalah sesuatu yang kita punya kode untuk saat ini.

Saya pikir ini adalah masalah yang cukup besar kecuali beberapa pekerjaan pendahuluan dilakukan secara terpisah terlebih dahulu. Kita perlu memiliki cara sewenang-wenang untuk menentukan dependensi antara item pekerjaan dan menjadwalkannya sesuai. Itu bukan bagaimana kita melakukannya sekarang. Kami tidak memiliki gagasan tentang item yang menunggu item lainnya selesai. Masalah #1096 bisa mengarah ke sana. Saat ini dijadwalkan pada tonggak 3.4.

Tentu saja, kita bisa melakukan semacam ketergantungan adhoc tanpa itu, tetapi kita mungkin akan mengulanginya pada akhirnya. IMO, grafik ketergantungan umum antara item pekerjaan adalah apa yang benar-benar ingin kita miliki. Kemudian menjadi sangat mudah untuk mengimplementasikan berbagai lapisan pengguna di atasnya.

BTW, sepertinya kita sering terlibat dalam diskusi luas seperti ini pada saat kita mencoba membawa pulang target rilis. Saya berharap kita bisa melakukannya di awal iterasi!

Saya sangat tertarik untuk mengerjakan item ini. Saya akan mulai dengan mengusulkan "sintaks" untuk menentukan ketergantungan. Pemesanan tes (tidak tergantung) akan menjadi bagian darinya. Saya juga ingin membuatnya bekerja dengan sintaks yang sama pada TestFixture serta Test.

Seperti yang telah dicatat, ini sudah ada sejak lama. Apakah masih terlalu dini untuk benar-benar memulai ini?

Tidak, tidak terlalu cepat untuk mengetahui sintaksnya. Saya sarankan Anda membuat Spesifikasi di wiki dev. Saya memiliki beberapa ide yang ingin saya sumbangkan... sebagaimana diuraikan secara singkat dalam salah satu komentar di atas. Saya pikir perbedaan utama adalah antara dependensi "keras", yang harus diikuti oleh NUnit, dan yang "lebih lembut", yang pada dasarnya hanyalah petunjuk untuk kerangka kerja.

Saya memiliki ide yang cukup bagus tentang cara mengimplementasikan ini, termasuk menggunakannya untuk mendorong fase SetUp dan TearDown yang dibahas dalam edisi #1096.

Itu berarti mengubah "pengiriman" tes dari mekanisme "dorong" saat ini menjadi mekanisme "tarik".

"Buat Spesifikasi di wiki dev"? Gak kebayang gimana caranya :(

Tidak yakin mengapa Anda menyebut pengiriman uji sebagai mekanisme "dorong". Pekerja menarik item dari antrian ketika mereka siap untuk mengeksekusinya. Saya berencana untuk mengerjakan #1096 dan saya menerima saran apa pun.

Bisakah Anda mengedit wiki? Saya akan membuat halaman kosong di tempat yang tepat jika Anda mau. Jika tidak, itu bisa berupa teks di sini, tentu saja, tetapi melakukannya di wiki akan memberi kita langkah awal untuk mendokumentasikannya nanti.

CompositeWorkItem pada dasarnya beralih di seluruh anak-anaknya, dan "mendorong" masing-masing untuk dieksekusi.

Saya melihat implementasi ketergantungan yang membangun "antrian" linier dari setiap item pekerjaan dalam pengujian, seperti antrian penjadwal dalam sistem operasi, yang menentukan kondisi di mana setiap item dapat diizinkan untuk dijalankan. Operator menghapus item pekerjaan "yang dapat dijalankan" teratas dari antrian untuk dijalankan (jika paralel, maka setiap "utas" pekerjaan akan menghapus item pekerjaan yang dapat dijalankan berikutnya yang dapat diparalelkan). Saat item pekerjaan selesai, item tersebut akan mengaktifkan "runabilitas" item lain dalam antrian, bahkan mungkin membuang item yang sekarang tidak akan pernah dijalankan karena ketergantungannya.

Bahkan dimungkinkan untuk mengekspresikan kemampuan paralel sebagai kondisi ketergantungan.

Saya melihat #1096 sebagai bagian tak terpisahkan dari proses yang sama. Setelah beberapa item pekerjaan dibuat, masing-masing akan diberi properti ketergantungan yang akan mengontrol kapan mereka dieksekusi.

Saya tidak tahu apakah saya bisa mengedit wiki. Belum pernah mencoba, dan tidak tahu caranya. Bisakah Anda memberi saya "dorongan" awal? :)

@oznetmaster , mengedit wiki cukup mudah,

1. Pilih halaman yang ingin Anda tambahkan tautan ke halaman wiki baru Anda, mungkin dari halaman Spesifikasi ,
2. Edit halaman dengan mengklik tombol
3. Tambahkan tautan dengan mengelilingi teks dengan tanda kurung siku ganda seperti [[My NUnit Spec]]
4. Simpan halaman
5. Melihat tautan baru, berwarna merah menunjukkan halaman tidak ada
6. Klik tautan merah, itu akan membawa Anda ke halaman buat baru
7. Edit halaman seperti yang Anda lakukan pada masalah menggunakan penurunan harga GitHub dan simpan

@oznetmaster Apa yang Anda gambarkan adalah cara kerja operator paralel. Item ditugaskan ke antrian individu tergantung pada karakteristiknya. Saat ini, ini memperhitungkan kemampuan paralel dan persyaratan Apartemen. Semua item, setelah antri, siap untuk dieksekusi.

Selalu direncanakan bahwa antrian ketergantungan akan ditambahkan sebagai langkah selanjutnya. Saya berencana menggunakan #1096 sebagai "alasan" untuk mengimplementasikan infrastruktur itu. Setelah diimplementasikan, selanjutnya dapat diekspos ke pengguna seperti yang diminta di #51. Saya akan menyiapkan spesifikasi untuk mekanisme penjadwalan yang mendasari (pengirim) juga dan saya ingin komentar Anda tentangnya.

@oznetmaster Saya membuat halaman kosong untuk Anda: https://github.com/nunit/dev/wiki/Test-Dependency-Attribute

Apakah kita berkomitmen untuk memanggil atribut DependsOnAttribute? Bagaimana dengan sesuatu yang lebih umum seperti "DependenciesAttribute"?

Ini menyebalkan, aku tahu :(

Anda harus menulisnya seperti yang Anda pikirkan. Lalu kita semua akan memperebutkannya. :-)

Jadi saya punya :)

Saran: tambahkan bagian yang menjelaskan motivasi untuk setiap jenis ketergantungan. Misalnya, kapan pengguna biasanya ingin menggunakan AfterAny, dll.

Sebagai pengembang, selalu tergoda untuk menambahkan sesuatu untuk "kelengkapan". Mencoba membayangkan pengguna yang membutuhkan setiap fitur adalah pengekangan yang berguna untuk kecenderungan ini. Sayangnya, pengguna umumnya hanya memberi tahu kami ketika ada sesuatu yang hilang, bukan ketika ada sesuatu yang tidak berguna bagi mereka.

Untuk apa nilainya, masukan saya:

Saya lebih suka tidak mendefinisikan _per metode pengujian_ ketergantungan, yang menjadi agak membosankan (dan sulit dipertahankan) jika Anda memiliki lebih dari beberapa tes. Alih-alih, saya ingin membuat pesanan di antara perlengkapan uji. Ini berasal dari kasus berikut yang saat ini kami miliki: Kami menggunakan MSTest untuk tes yang dipesan saat ini. Kecuali MSTest, ini berfungsi dengan baik, karena dengan urutan pengujian saya dapat mengungkapkan dua hal tentang pengujian: Tes tertentu _mungkin tidak dijalankan sebelum_ tes lain. Tes lain memiliki _ketergantungan_ pada tes lain dan hanya dapat _dieksekusi setelah_ tes lain dieksekusi.

Katakanlah tes integrasi:

• Menggunakan database uji dengan beberapa akun pengguna di dalamnya
• Beberapa pengujian pertama menjalankan beberapa pengujian menggunakan data pengujian, dan juga membuat data pengujian itu sendiri untuk digunakan dalam pengujian selanjutnya. Perhatikan bahwa kita memiliki hubungan _dependency_ di sini. Beberapa tes mungkin tidak dijalankan jika tes sebelumnya gagal.
• Kemudian beberapa tes otomatisasi browser terjadi. Mereka harus dieksekusi selambat mungkin, karena mereka membutuhkan banyak waktu dan kami ingin mendapat umpan balik dari tes sebelumnya (lebih cepat) terlebih dahulu.
• Akhirnya, beberapa logika diuji yang menghapus seluruh akun pengguna. Perhatikan bahwa kita memiliki hubungan _must not execution before_ di sini: Jika pengujian ini dilakukan sebelum pengujian lainnya, pengujian lainnya akan gagal.

Dengan MSTest saya dapat mengungkapkan kasus ini dengan baik: Setiap 'tes yang dipesan' di MSTest dapat berisi tes yang dipesan itu sendiri. Selain itu, pengujian yang dipesan dapat memiliki flag yang disetel untuk dibatalkan jika salah satu pengujian gagal.

              /      |         \
   DomainTests  BrowserTests  DestructiveTests
    /   |  \       /  |   \      |   \ 
   A    B   C     D   E    F     G    H 

Misalnya, MyPrimaryOrderedTest gagal 'batalkan kegagalan' disetel ke false. Tidak ada yang mencegah BrowserTests untuk dieksekusi jika DomainTests gagal. Namun, DomainTests sendiri memiliki flag yang disetel ke true sehingga pengujian C tidak dijalankan jika A atau B gagal. Perhatikan bahwa A sampai H dapat berupa definisi tes yang dipesan itu sendiri atau perlengkapan tes.

Untuk lebih jelasnya, jika memikirkan antarmuka seperti ini untuk mengekspresikan pemesanan perlengkapan uji:

interface ITestCollection {
    IEnumerable<Type> GetFixtureTypes();
    bool ContinueOnFailure { get; }
}

Ini jauh lebih dapat dipertahankan (dan jelas) karena memiliki atribut ketergantungan pada setiap perlengkapan dan skala jauh lebih baik karena jumlah perlengkapan meningkat.

Catatan untuk pengujian pemesanan _within_ fixtures, saya hanya akan menggunakan OrderAttribute yang ada untuk itu. Saya pikir metode pengujian seharusnya tidak memiliki ketergantungan pengujian antar-perlengkapan, karena itu membuat struktur pengujian terlalu rumit dan tidak dapat dipertahankan.

Untuk pemesanan pengujian antar perlengkapan, saya telah menyiapkan prototype , dan saya telah menemukan bahwa mengekspresikan ketergantungan antar perlengkapan dengan menggunakan atribut menjadi berantakan, bahkan hanya dengan beberapa pengujian. Harap perhatikan juga bahwa prototipe tidak akan mengizinkan pemesanan di luar namespace yang ditentukan oleh fixture karena setiap fixture adalah bagian dari pengujian induk dengan nama namespace. Saya perlu mengimplementasikan ITestAssemblyBuilder saya sendiri untuk mengatasinya tetapi NUnit di-hardcode untuk menggunakan DefaultTestAssemblyBuilder saat ini.

Pembaruan dari pihak saya: Sementara itu saya telah berhasil menerapkan pemesanan pengujian tanpa perlu membayar NUnit. Ini "cukup baik" untuk saya, jadi saya menggunakannya sekarang. Ini sudah jauh lebih baik daripada keadaan rapuh dari banyak tes yang dipesan MSTest.

Karena penasaran -- apakah ada kemungkinan fitur Ketergantungan direncanakan untuk rilis berikutnya?

Tidak ada rencana saat ini. FYI, Anda dapat melihatnya di sini di GitHub berdasarkan fakta bahwa itu tidak ditugaskan kepada siapa pun dan tidak memiliki tonggak yang ditentukan.

Untuk item prioritas normal, seperti ini, kami biasanya tidak merencanakannya terlebih dahulu untuk rilis tertentu. Kami mencadangkannya untuk item tinggi dan kritis. Yang ini hanya akan masuk ke rencana rilis ketika seseorang memutuskan ingin melakukannya, menetapkannya sendiri, dan membawanya ke titik di mana ia siap untuk digabungkan.

Faktanya, meskipun tidak benar-benar bergantung padanya, masalah ini memang membutuhkan banyak hal dari #164 untuk dapat dikerjakan secara efektif. Saya sedang mengerjakannya dan berharap untuk mendorongnya ke rilis berikutnya.

Relevan: https://stackoverflow.com/questions/44112739/nunit-using-a-separate-test-as-a-setup-for-a-subsequent-test

Direferensikan ke sini dari sana. Saya sangat percaya bahwa kesalahan apa pun seharusnya hanya menyebabkan satu unit tes gagal, memiliki sejumlah besar lainnya gagal karena mereka bergantung pada kesalahan itu tidak ada .. tidak diinginkan di terbaik, dan lebih dari sedikit waktu memakan waktu untuk mencoba melacak tes mana yang gagal yang relevan.

Sunting: Hanya dengan melihat kode saya yang ada, saya memiliki metode 'Prasyarat (Tindakan tindakan)' di banyak perlengkapan pengujian saya yang membungkus ajakan untuk bertindak dalam try/catch AssertionException/throw Tidak meyakinkan, tetapi juga melakukan beberapa pembersihan hal-hal seperti 'substitute.ClearReceivedCalls' (dari NSubtitute) dan mengosongkan daftar yang diisi oleh 'testObj.PropertyChanged += (pengirim,e) => diterimaEvents.Add(e.PropertyName)'; jika tidak, tindakan masa lalu berpotensi mencemari panggilan ke 'pengganti.Diterima..'

Mungkin perlu juga menyertakan semacam metode 'Pembersihan' dalam atribut ketergantungan untuk mendukung hal-hal seperti ini.

@ Flynn1179 - Saya setuju dengan Anda dalam hal tes _unit_. Namun, NUnit juga merupakan alat yang hebat untuk jenis tes lainnya. Misalnya, kami menggunakannya untuk menguji firmware yang disematkan dan benar-benar kehilangan fitur ini...

@ Flynn1179 Sepenuhnya setuju dengan Anda. Ada teknik untuk mencegah kegagalan palsu seperti yang Anda jelaskan yang tidak "bergantung" pada memiliki fitur ketergantungan pengujian. Secara umum, gunakan asumsi untuk menguji hal-hal yang benar-benar diuji dalam pengujian yang berbeda dan diperlukan agar pengujian Anda masuk akal.

Itu adalah tujuan dari NUnit 3 untuk memperluas NUnit untuk penggunaan yang efektif dengan pengujian non-unit. Kami benar-benar belum melakukannya - mungkin menunggu rilis besar lainnya. OTOH, pengguna terus menggunakannya untuk tujuan lain tersebut dan mencoba menemukan cara cerdas untuk mengatasi keterbatasan. Di sana-sini kami telah menambahkan fitur-fitur kecil dan peningkatan untuk membantu mereka, tetapi ini benar-benar masih merupakan kerangka kerja pengujian unit.

Secara pribadi, saya ragu saya ingin menggunakan ketergantungan sebagai bagian dari pengujian tingkat tinggi sendiri. Sebaliknya, saya lebih suka memiliki jenis perlengkapan berbeda yang menjalankan serangkaian langkah dalam urutan tertentu, melaporkan keberhasilan atau kegagalan setiap langkah dan melanjutkan atau menghentikan berdasarkan beberapa properti langkah. Itu, bagaimanapun, adalah masalah lain.

@espenalb Saya akan tertarik untuk mengetahui apa yang Anda rasa diperlukan terutama untuk menguji firmware yang disematkan.

Kami sebenarnya sangat senang dengan apa yang ditawarkan NUnit.

Kami menggunakan kombinasi atribut FixtureSetup/Setup/test untuk mengonfigurasi perangkat (Termasuk flashing firmware)

Kemudian kami menggunakan antarmuka yang berbeda (port serial, jtag, ethernet) untuk berinteraksi dengan perangkat, biasanya kami mengirim beberapa perintah dan kemudian mengamati hasilnya. Hasil dapat berupa respons perintah, atau dalam pengujian lanjutan kami menggunakan peralatan perangkat keras khusus untuk mengukur perilaku perangkat.

Makro pernyataan NUnit, dan FluentAssertions kemudian digunakan untuk memverifikasi bahwa semuanya baik-baik saja.
Menurut definisi, ini semua adalah tes integrasi - dan secara alami jauh lebih lambat daripada tes unit biasa. Oleh karena itu, masalah ketergantungan pengujian sangat terlewatkan - tidak ada gunanya memverifikasi misalnya kinerja sensor jika perintah untuk mengaktifkan sensor ditolak. Kemampuan untuk mengambil satu tes di mana yang lain selesai karena itu sangat berharga.

Dengan atribut dependensi pengujian, kita akan memiliki _satu_ pengujian yang gagal, kemudian _n_ mengabaikan/melewati pengujian di mana pengujian yang dilewati dapat dengan jelas menyatakan bahwa pengujian tersebut tidak dijalankan karena pengujian lainnya gagal...

Perbedaan lain dari pengujian unit biasa adalah penggunaan berat penulis log. Ada satu masalah di sana mengenai multithreading dan log yang akan saya buat masalah terpisah jika belum ada.

Intinya dari kami - kami _sangat_ senang dengan NUnit sebagai alat uji untuk pengujian integrasi. Ini memberi kami dukungan yang sangat baik untuk banyak skenario lanjutan dengan menggunakan C# untuk berinteraksi dengan Device Under Test dan peralatan lab lainnya.

Dengan ReportUnit kami kemudian mendapatkan laporan html yang bagus dan kami juga mendapatkan integrasi Jenkins dengan menggunakan output pengujian nunit rev2.

kami juga mendapatkan integrasi Jenkins dengan menggunakan output pengujian nunit rev2.

@espenalb - Selesaikan, tetapi plugin Jenkins baru-baru ini diperbarui untuk membaca keluaran NUnit 3. 🙂.

Dapatkah seseorang memberikan sedikit pembaruan tentang status fitur ini? Apakah itu direncanakan?
Di departemen saya, kami melakukan tes yang berjalan sangat lama, yang secara logis sangat bergantung satu sama lain.
Semacam "Test-Dependency" akan sangat menarik dan membantu kami...

Saya mendengar bahwa Anda secara umum berencana untuk "membuka" NUnit untuk tes "pengujian non-unit" juga (yang pada dasarnya berlaku untuk kami ...). Saya pikir atribut ini akan menjadi satu langkah menuju itu :-)

Fitur ini masih dalam tahap desain, jadi selain menggunakan library eksternal, saat ini tidak ada dukungan bawaan.

Saya minta maaf untuk menarik utas lama tetapi selama bekerja meskipun NUnit dengan seorang teman kami menemukan kasus di mana jika kami memiliki fitur seperti itu, kami dapat mulai membuat tes integrasi (saya menyadari NUnit adalah Kerangka Pengujian Unit, tetapi sepertinya kita bisa mendapatkan apa yang kita inginkan jika kita memiliki Test Dependency).

Pertama, inilah tautan yang diperbarui ke spesifikasi yang diusulkan (tautan dari CharliePoole di sini https://github.com/nunit/nunit/issues/51#issuecomment-188056417 sudah mati): https://github.com/nunit/docs/ wiki/Test-Dependency-Attribute-Spec

Sekarang untuk kasus penggunaan; pertimbangkan Program mainan berikut dan Tes Terkait

namespace ExampleProgram
{
    using System.Collections;
    using NUnit.Framework;

    public static class ExampleClass
    {
        public static int Add(int a, int b)
        {
            return a - b;
        }

        public static int Increment(int a)
        {
            return Add(a, 1);
        }
    }

    public class ExampleClassTests
    {
        [TestCaseSource(typeof(AddTestCases))]
        public void Add_Tests(int a, int b, int expected)
        {
            int actual = ExampleClass.Add(a, b);
            Assert.That(actual, Is.EqualTo(expected));
        }

        [TestCaseSource(typeof(IncrementTestCases))]
        public void Increment_Tests(int a, int expected)
        {
            int actual = ExampleClass.Increment(a);
            Assert.That(actual, Is.EqualTo(expected));
        }
    }

    internal class IncrementTestCases : IEnumerable
    {
        public IEnumerator GetEnumerator()
        {
            yield return new TestCaseData(0, 1);
            yield return new TestCaseData(-1, 0);
            yield return new TestCaseData(1, 2);
        }
    }

    internal class AddTestCases : IEnumerable
    {
        public IEnumerator GetEnumerator()
        {
            yield return new TestCaseData(0, 0, 0);
            yield return new TestCaseData(0, 2, 2);
            yield return new TestCaseData(2, 0, 2);
            yield return new TestCaseData(1, 1, 2);
        }
    }
}

Sebagai pelaksana, saya tahu bahwa jika ada Tes Unit di sekitar Add(int,int) yang gagal, sama sekali tidak ada gunanya menjalankan semua tes tambahan di sekitar Increment(int) selain noise. Namun tampaknya tidak ada cara (kependekan dari Test Dependency) untuk menentukan ini ke NUnit (setidaknya dalam pencarian saya).

Melakukan banyak riset online sepertinya orang lain telah mengatasi ini dengan menggunakan kombinasi faktor (tidak ada yang secara eksplisit jelas bahwa Increment(int) bergantung pada Add(int,int) ) cara-cara tersebut meliputi:

• Menggunakan Kategori
• Menggunakan Konvensi Penamaan Untuk Mengontrol Urutan Tes

Tak satu pun dari ini tampaknya berskala baik, atau bahkan berfungsi dalam hal ini ketika Anda menggunakan fitur lain seperti Paralel dan semuanya memerlukan beberapa "pemrosesan pasca" eksternal setelah proses NUnit selesai.

Apakah ini jalan terbaik ke depan (jika kita menggunakan NUnit murni)? Apakah fitur ini masih dikerjakan? (Dengan kata lain jika PR diajukan, apakah itu akan membuat orang lain macet mengerjakan sesuatu yang terkait?)

Ada banyak diskusi bagus di utas ini tentang dependensi siklik dan masalah potensial lainnya dengan fitur ini, jelas tidak mudah untuk memperbaikinya jika tidak, seseorang pasti sudah melakukannya. Saya yakin menambahkan Parallel dan TestCaseSource ke dalam campuran juga meningkatkan kompleksitas. Saya berniat untuk menggali lebih banyak di beberapa titik, tetapi sebelum melakukannya ingin memastikan bahwa ini bukan masalah yang terpecahkan atau rencana yang sedang dikerjakan.

@aolszowka
Ini tetap menjadi fitur yang diterima, setidaknya sejauh label masalah pergi. @nunit/framework-team Apakah saya benar di sana?

Tidak ada yang menugaskannya untuk diri mereka sendiri, yang berarti tidak ada yang mengerjakannya. Pintar Anda bertanya, tidak kurang! Jika Anda ingin mengerjakannya, beberapa anggota tim mungkin akan menugaskannya untuk diri mereka sendiri dan "mengawasi" Anda, karena GitHub tidak mengizinkan kami menugaskan masalah kepada non-anggota.

Saya menjadikan ini fitur dan memberikannya prioritas "normal" kembali ketika saya memimpin proyek. Saya bermaksud untuk mengerjakannya "suatu hari nanti" tetapi tidak pernah melakukannya dan tidak akan pernah sekarang karena saya tidak aktif dalam proyek tersebut. Saya senang berkorespondensi dengan Anda tentang masalah apa pun yang Anda temukan jika Anda menerimanya.

Saran saya adalah untuk TIDAK melakukan apa yang saya coba lakukan: tulis spesifikasi lengkap dan kemudian kerjakan. Seperti yang dapat Anda baca di komentar, kami terus menemukan hal-hal yang tidak disetujui dalam spesifikasi dan tidak ada yang pernah memindahkannya ke implementasi. AFAIK (atau ingat) pekerjaan prasyarat dalam cara pengiriman tes telah dilakukan. Saya akan memilih salah satu dari tiga jenis ketergantungan (lihat komentar saya dua+ tahun yang lalu) dan hanya satu kasus penggunaan dan mengerjakannya. Kami tidak ingin merilis sesuatu sampai kami yakin bahwa API sudah benar, jadi Anda mungkin harus mengandalkan cabang fitur yang berjalan lama yang harus secara berkala di-rebase atau digabungkan dari master. Pekerjaan besar!

Ini tetap menjadi fitur yang diterima, setidaknya sejauh label masalah pergi. @nunit/framework-team Apakah saya benar di sana?

Ya - sejauh yang saya ketahui!