Nunit: Jalankan metode pengujian dalam perlengkapan secara paralel

Pembaruan: Baik komentar ini dan yang berikut ini membalas seseorang yang tampaknya menghapus komentarnya sendiri. Saya meninggalkan jawaban saya.

Baik itu dalam spesifikasi dan dijadwalkan untuk implementasi pasca-3.0. Jika itu begitu mudah, kita mungkin akan melakukannya. Tidak yakin koneksi apa yang Anda lihat dengan mbunit. Fakta bahwa mereka memilikinya tidak membantu kami.

Ini mulai sedikit melelahkan. Beberapa poin, sudah dinyatakan tetapi tampaknya terlewatkan ...

1. Ada rencana untuk mengimplementasikan apa yang Anda minta.
2. Kami memutuskan sebagai tim untuk menjadwalkannya pada titik tertentu.
3. Kapan dijadwalkan terutama berkaitan dengan penilaian kami tentang nilai fitur tersebut dibandingkan dengan fitur lainnya.
4. Ada beberapa orang di tim NUnit yang dapat mengimplementasikan fitur tersebut.
5. Mereka akan dapat menerapkannya, tergantung pada prioritas, di luar kepala mereka dan tidak perlu menyalinnya dari mana pun.

Saya menemukan pembicaraan Anda tentang "rekayasa balik" sangat mengganggu. Sumber terbuka hanya dimungkinkan dalam konteks di mana hak cipta dihormati. Jadi, jika Anda menyarankan agar kami mengabaikan persyaratan lisensi mbunit, Anda jauh dari dasar.

Sementara saya berkontribusi banyak tambalan ke MbUnit dan menggunakannya selama bertahun-tahun, saya
tidak pernah menjadi kontributor utama. Saya tidak ingin status saya disalahartikan :)

Adapun rekayasa balik, sebenarnya tidak ada gunanya di sini. NUnit berfungsi
sama sekali berbeda dari MbUnit. Kami akan menyelesaikan masalah ini pada waktunya,
tetapi mendekatinya dengan hati-hati karena masalah serupa lainnya mungkin berubah
cara kita perlu menerapkan ini atau bahkan konflik.
Pada 19 April 2015 2:45, "CharliePoole" [email protected] menulis:

Ini mulai sedikit melelahkan. Beberapa poin, sudah dinyatakan tapi
ternyata ketinggalan...

1.

Ada rencana untuk mengimplementasikan apa yang Anda minta.
2.

Kami memutuskan sebagai tim untuk menjadwalkannya pada titik tertentu.
3.

Ketika dijadwalkan terutama berkaitan dengan penilaian kami tentang
nilai fitur dibandingkan dengan fitur lainnya.
4.

Ada beberapa orang di tim NUnit yang bisa menerapkan
fitur.
5.

Mereka akan dapat mengimplementasikannya, tergantung pada prioritas, di luar
kepala mereka dan tidak perlu menyalinnya dari mana pun.

Saya menemukan pembicaraan Anda tentang "rekayasa balik" sangat mengganggu. Sumber terbuka adalah
hanya mungkin dalam konteks di mana hak cipta dihormati. Jadi jika Anda
menyarankan agar kami mengabaikan persyaratan lisensi mbunit, Anda jauh
basis.

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

Komentar yang jauh lebih bijaksana daripada komentar saya!

Prioritas kami saat ini di dunia paralel execution adalah:

1. Eksekusi proses paralel
2. Grup pengecualian
3. Metode paralel (dalam satu perlengkapan) eksekusi.

Ini tampaknya mewakili urutan kegunaan terbesar bagi pengguna.

Saya juga akan menyebutkan bahwa menandai sesuatu sebagai post-3.0 tidak berarti fitur tersebut datang lebih lambat daripada jika kita menjadikannya bagian dari 3.0. Sebaliknya, itu mungkin berarti bahwa 3.0 datang pada titik waktu yang lebih awal.

Ketika kita melakukan ini, kita harus memutuskan bagaimana menangani perintah setup dan teardown. Pilihan termudah kemungkinan akan membangun kelas tes untuk setiap tes sehingga tidak ada pertentangan untuk data.

Saya lebih suka menjadikannya opsi di beberapa titik, tetapi saya tidak yakin apakah itu opsi run atau opsi fixture-by-fixture (dikaitkan) atau keduanya.

Hai!
Penambahan fitur ini ke versi NUnit berikutnya akan sangat bagus, karena ini adalah satu-satunya hal yang mencegah saya beralih ke NUnit. Apakah fitur ini masih direncanakan untuk 3.4?

@julianhaslinger NUnit 3.4 akan keluar pada akhir bulan, jadi tidak, fitur ini tidak akan disertakan.

FYI, masalah ini ada di tonggak Backlog kami (atau tonggak semu) daripada 3.4 karena kami mengikuti praktik hanya menambahkan sejumlah kecil masalah pendefinisian kunci ke setiap tonggak bernomor sebelumnya.

Tonggak berikutnya, 3,6, dijadwalkan turun dalam 3 bulan lagi, yang mungkin terdengar mengecewakan bagi Anda. :-( Namun, jika Anda melihat masalah ini digabungkan ke master, Anda akan bisa mendapatkan penurunan lebih awal dari umpan MyGet kami.

@julianhaslinger ini tidak akan dalam 3.4 yang mungkin keluar hanya dalam waktu seminggu, tetapi ini adalah salah satu yang saya ingin segera selesai, jadi suara Anda membantu :+1:

Selain itu, kerangka pengujian mana yang Anda gunakan yang mendukung eksekusi metode paralel? Saya pikir XUnit hanya mengizinkan menjalankan tes secara paralel hingga ke tingkat Kelas juga. Apakah saya salah? Saya tidak banyak menggunakan XUnit :smile:

@CharliePoole Terima kasih atas jawabannya! Oke, ini terdengar agak mengecewakan. Namun, saya akan menunggu rilis berikutnya (atau rilis sebelumnya). Harap (masih) pertimbangkan fitur ini di versi berikutnya (3.6).

@rprouse Saya menggunakan MbUnit/Gallio sekarang. Proyek ini hampir mati dan sekarang saya akan beralih ke NUnit.

@julianhaslinger Apakah ini masalah waktu berjalan untuk Anda? Apakah Anda memiliki beberapa angka tentang distribusi kasus uji dalam perlengkapan? Saya bertanya karena asumsi saya adalah bahwa fitur tersebut memberikan sedikit kepada pengguna di luar apa yang mereka dapatkan dari perlengkapan paralel. Jika itu salah, itu bisa mengubah prioritas relatifnya.

@CharliePoole Tepat, masalah kami yang sebenarnya adalah waktu berjalannya kasus uji. Kami ingin menggunakan NUnit untuk pengujian otomatis/regresi kami (termasuk Selenium/WebDriver) dan karena beberapa kelas pengujian kami memiliki 200+ kasus pengujian, saat ini sangat sulit untuk menjalankan seluruh rangkaian pengujian dengan NUnit.

Perbandingan (dalam set pengujian yang lebih kecil dari pengujian regresi kami) telah menunjukkan bahwa solusi NUnit yang mungkin akan dieksekusi dalam waktu sekitar 1,5 jam sedangkan solusi MBunit saat ini akan dieksekusi dalam 0,5 jam (set pengujian yang sama).

Namun, @CharliePoole , saya menyadari fakta bahwa kami mungkin dapat mengurangi waktu eksekusi dengan membagi kelas pengujian yang lebih besar menjadi yang lebih kecil, tetapi ini entah bagaimana akan merusak ide awal hierarki kelas pengujian kami.

@julianhaslinger - Hanya untuk mengonfirmasi, apakah Anda yakin waktu yang Anda jalankan terikat CPU, dan tidak terikat memori?

Kami mengalami masalah yang sama saat pertama kali mencoba beralih ke NUnit 3 - waktu berjalan menjadi jauh lebih lama. Ini karena NUnit memaksimalkan memori yang tersedia - ada masalah dengan versi saat ini yang mempertahankan semua objek uji hingga uji coba selesai. Kami sedang menjalankan versi yang ditambal secara internal - saya ingin mendapatkan PR untuk 3.4, tetapi tidak yakin saya akan punya waktu pada saat ini. :-(

Maaf jika ini bukan, tetapi saya pikir itu layak disebutkan, karena Selenium dapat menggunakan bagian memori yang adil. :-)

@ChrisMaddock Terima kasih atas masukannya! :+1: Kami akan segera melihatnya dan saya akan kembali kepada Anda.

@ChrisMaddock Saya ingin melihat memori Anda diperbaiki di 3.4. Jika Anda ingin memasang PR, kami dapat membantu Anda membersihkannya jika belum siap untuk produksi :+1:

@rprouse - https://github.com/nunit/nunit/pull/1367/commits/5f98ae51025f7af8244abd4367d1f47260874dfc di PR #1367 membebaskan segalanya dengan benar untuk kami, dalam v3.0.1 yang ditambal.

Anda akan melihat di PR bahwa itu dipindahkan ke OneTimeTearDown sebelum bergabung - Saya belum tahu apakah langkah itu menyebabkannya tidak berfungsi di v3.2.1, atau jika ada perubahan lain yang berfungsi yang memperkenalkan kembali retensi - Saya mungkin tidak menguji ulang setelah pindah.

Akan mencoba dan menguji ulang dan membuangnya besok, akan sangat bagus bagi kami untuk kembali ke rilis inti juga. :-)

@ChrisMaddock Saya telah melihat konsumsi memori selama uji regresi dan menemukan bahwa pelaksanaan uji coba tidak terikat memori. Saya kira kita benar-benar harus menunggu versi NUnit yang dapat menangani eksekusi paralel metode individual di dalam setiap kelas.

hanya untuk menambahkan apa yang dikatakan @julianhaslinger , saya telah melihat masalah yang persis sama dalam menggunakan NUnit dengan tes Selenium. Saya harus menulis pembungkus khusus yang menjalankan masing-masing instance nunit-console.exe terhadap satu tes sebagai tergores dari perakitan yang lulus sehingga saya bisa menjalankan tes paralel untuk saat ini. Ini tidak ideal karena menghasilkan banyak file keluaran .xml yang dihasilkan (satu untuk setiap uji coba) daripada satu keluaran .xml dan itu juga berarti saya tidak dapat menggunakan _OneTimeSetUp_ dan metode teardown dan sebagai gantinya harus bergantung pada semaphore eksternal dan variabel lingkungan untuk mengontrol aliran eksekusi di mana saya hanya ingin menjalankan sesuatu sekali. Saya telah mengikuti janji untuk memiliki eksekusi paralel di NUnit untuk waktu yang lama sekarang (bertahun-tahun) dan sangat kecewa dengan bagaimana fitur tersebut diluncurkan di 3.0 (hanya sebagian didukung dan membutuhkan beberapa penggalian nyata dalam masalah dan merilis catatan untuk temukan tidak semuanya benar-benar didukung). Saya bahkan melangkah lebih jauh untuk menyelidiki apa yang akan terlibat dalam memajukan ini sendiri, tetapi sayangnya tampaknya desain NUnit bekerja melawan implementasi eksekusi paralel pada tingkat metode pengujian, saya tidak tahu bagaimana Anda sebenarnya ingin untuk menangani potensi kode non-threadsafe (yaitu haruskah diserahkan kepada orang yang menggunakan NUnit secara paralel untuk memastikan semua metode pengujian merujuk dengan benar eksternal apa pun dengan cara yang aman atau haruskah NUnit sendiri menangani eksekusi setiap metode di domainnya sendiri sementara entah bagaimana mencoba untuk tetap hanya menjalankan metode pengaturan satu kali dan metode tipe teardown hanya sekali) dan karena saya sudah memiliki solusi, saya tidak dapat membenarkan waktu dalam mengimplementasikan fitur ini sendiri (yang mungkin yang terbaik karena saya telah dibakar sebelumnya ketika bekerja dengan tim di GitHub untuk membantu mereka menerapkan eksekusi paralel). Ngomong-ngomong... maaf bertele-tele... Saya mengerti bahwa prioritas untuk Pengujian Unit kode C# mungkin tidak terlalu bergantung pada paralelisme tingkat metode, tetapi perlu diketahui bahwa bagi kita yang menggunakan NUnit untuk pengujian berbasis Selenium itu akan menjadi peningkatan BESAR. Terima kasih sebelumnya! :senyum:

Terima kasih atas komentar Anda. Saya pikir saya akan mengoceh sedikit sendiri di sini ...

Ini membantu untuk memahami apa yang dibutuhkan orang dan mengapa mereka membutuhkannya. Bukan menjadi pengembang web sendiri, saya mencoba mendengarkan pengguna Selenium dan fokus pada apa yang mereka inginkan. Apa yang tampak adalah perlengkapan paralel dengan pemesanan di antara kasus uji. Saya sepenuhnya memahami bahwa orang yang berbeda akan menginginkan hal yang berbeda, tetapi ketika kedua kelompok menampilkan diri mereka sebagai mengekspresikan "apa yang dibutuhkan pengguna Selenium" itu agak membingungkan. Bisakah Anda menguraikan untuk saya jenis tes web apa yang mungkin menginginkan paralelisme tingkat metode yang bertentangan dengan orang-orang yang ingin menjalankan metode dalam urutan yang telah ditentukan sebelumnya? Saya pikir saya bisa menebak, tetapi saya lebih suka memilikinya dari pengguna.

Mengenai solusi Anda ... apakah Anda mempertimbangkan untuk menggunakan rakitan tes terpisah? NUnit akan dengan senang hati menjalankan masing-masing secara paralel dalam proses terpisah. Tentu saja itu tidak menghilangkan kebutuhan untuk menyinkronkan akses ke hal-hal seperti file.

Mengenai keamanan utas - kami tidak pernah merencanakan implementasi paralel kami untuk bertanggung jawab atas keamanan utas. Satu-satunya hal yang saya harapkan untuk menjamin adalah bahwa NUnit tidak akan membuat masalah keamanan utas jika metode Anda sudah aman untuk utas. Itu sendiri ternyata tidak sepele.

Terima kasih atas tanggapannya. Saya sangat memahami komentar Anda tentang
pemesanan eksekusi tes dalam fixture dan pemisahan tes menjadi terpisah
majelis.

Saya sudah menjadi pengguna NUnit dan telah bertahun-tahun (dan JUnit sebelum itu)
jadi ide untuk mengandalkan pemesanan tes di fixture bahkan tidak
pertimbangan dalam desain pengujian saya. Setiap tes mencoba untuk menjadi sepenuhnya dienkapsulasi
tindakan atau serangkaian tindakan di dalam situs tanpa harapan atas urutan
eksekusi. Desain situs yang saya uji juga berarti banyak pengujian
dapat memakan waktu hingga 20 menit untuk dieksekusi (sebagian besar waktu ini dihabiskan untuk menunggu
untuk hal yang terjadi di situs) dan jenis pengujian meliputi
beberapa skenario serupa sehingga kelas uji dasar digunakan untuk mengurangi kode
duplikasi dan meningkatkan pemeliharaan dengan menggunakan kelas dasar umum
metode. Tes diatur ke dalam proyek terpisah berdasarkan dev
kepemilikan tim atas area itu (jadi kami memang menggunakan majelis terpisah, tetapi ada
banyak tes per perakitan dan pembungkus tes saya akan menangani eksekusi
semua tes di semua lulus dalam rakitan secara paralel seperti yang dibuat sebelumnya
rilis resmi pertama NUnit 3 dan saya ingin memastikan semua tes telah
potensi untuk dieksekusi secara bersamaan dengan utas yang cukup
tersedia).

Pada dasarnya, Anda dapat membayangkan bahwa satu rakitan mungkin memiliki 10 tes dan
100 tes lainnya, tetapi perakitan dengan 10 tes membutuhkan waktu 10 menit
masing-masing sedangkan perakitan dengan 100 memiliki tes yang memakan waktu masing-masing 1 menit. Jika saya
memiliki mesin yang mampu menjalankan 110 utas paralel (yang sebenarnya
bagian dari desain infrastruktur kami) maka saya berharap tes selesai
dalam 10 menit, bukan dalam 100 menit.

Semoga ini bisa membantu menjelaskan ... maaf jika hal-hal masih belum sepenuhnya jelas,
tetapi intinya adalah bahwa paralelisme tingkat metode adalah sesuatu yang saya miliki
terlihat hilang di perpustakaan pengujian lain (prspec di Ruby misalnya) dan ketika
melakukan analisis peningkatan kinerja yang akan didapat dengan menambahkannya i
menemukan itu bisa menjadi perubahan positif yang besar. Lihat berikut ini sebagai contoh:
https://github.com/bicarbon8/rspec-parallel/wiki/Contoh
Pada 1 Jul 2016 00:45, "CharliePoole" [email protected] menulis:

Terima kasih atas komentar Anda. Saya pikir saya akan mengoceh sedikit sendiri di sini ...

Ini membantu untuk memahami apa yang dibutuhkan orang dan mengapa mereka membutuhkannya. Tidak menjadi
pengembang web sendiri, saya mencoba mendengarkan pengguna Selenium dan fokus pada apa
mereka ingin. Apa yang tampak adalah perlengkapan paralel dengan pemesanan
antara kasus uji. Saya sepenuhnya memahami bahwa orang yang berbeda akan menginginkannya
hal yang berbeda, tetapi ketika kedua kelompok menampilkan diri sebagai mengekspresikan
"apa yang dibutuhkan pengguna Selenium" agak membingungkan. Bisakah Anda menguraikan untuk saya?
jenis tes web apa yang mungkin menginginkan paralelisme tingkat metode sebagai lawan dari
orang-orang yang ingin menjalankan metode dalam urutan yang telah ditentukan sebelumnya? Saya pikir saya bisa
tebak, tapi saya lebih suka memilikinya dari pengguna.

Mengenai solusi Anda ... apakah Anda mempertimbangkan untuk menggunakan tes terpisah?
majelis? NUnit akan dengan senang hati menjalankan masing-masing secara paralel secara terpisah
proses. Tentu saja itu tidak menghilangkan kebutuhan untuk menyinkronkan akses ke
hal-hal seperti file.

Mengenai keamanan utas - kami tidak pernah merencanakan implementasi paralel kami
untuk bertanggung jawab atas keamanan benang. Satu-satunya hal yang saya harapkan
jaminannya adalah NUnit tidak akan _membuat_ masalah keamanan utas jika Anda
metode sudah thread-safe. Itu sendiri ternyata tidak sepele.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/nunit/nunit/issues/164#issuecomment -229819324, atau bisukan
benang
https://github.com/notifications/unsubscribe/ACNsyoczCUV9L7kbF2SHB7lLsyBKlrv9ks5qRFUJgaJpZM4CUZ8r
.

Terima kasih atas infonya... sangat membantu untuk melihat berbagai perspektif.

5 sen saya.

Dalam proyek kami, kami memiliki ~25 rakitan uji dan eksekusi uji paralel dari pengujian per rakitan dan per perlengkapan sudah sangat mengurangi waktu eksekusi. Eksekusi pengujian paralel dalam perlengkapan akan lebih meningkatkannya. Sekarang kami bahkan membagi sebagian besar perlengkapan yang memakan waktu menjadi beberapa perlengkapan untuk mempercepat eksekusi, tetapi akan jauh lebih baik jika nunit akan menjalankan tes perlengkapan secara paralel.

Apa yang benar-benar ingin saya lihat di nunit adalah paralelisasi uji pada tingkat kasus uji, karena membagi pengujian tersebut menjadi perlengkapan tidak selalu nyaman dan menyebabkan duplikasi kode. Kami memiliki beberapa pengujian yang dapat memakan waktu hingga beberapa ribu kasus uji (setiap kasus dieksekusi dengan cepat tetapi secara total membutuhkan waktu beberapa menit) atau hanya lusinan kasus (tetapi setiap kasus lambat) dan untuk saat ini pengujian tersebut merupakan penghalang utama untuk kita.

Terima kasih atas masukannya... ini adalah area yang akan kami bahas dalam rilis berikutnya bersama dengan masalah yang saling bersaing tetapi saling melengkapi untuk memastikan bahwa beberapa tes tidak berjalan secara paralel satu sama lain!

Pertanyaan saya sebelumnya lebih tentang bagaimana orang menulis tes, terutama saat mengemudikan aplikasi web. Beberapa orang bersikeras bahwa mereka ingin setiap metode menjadi langkah berurutan dan perlengkapan untuk mewakili serangkaian langkah tersebut. Ini tentu saja tidak paralel menurut definisi. Orang lain tampaknya menulis tes yang sangat mirip tanpa mengurutkan tes. Dugaan saya adalah bahwa kelompok yang terakhir menulis metode pengujian yang lebih besar, dengan serangkaian tindakan dan pernyataan di masing-masing metode.

@CharliePoole Berita bagus! Terima kasih banyak!

Menurut pendapat saya, kasus uji harus diisolasi dan tidak bergantung pada kasus uji lain atau perintah eksekusi. Jika orang masih ingin menjalankan beberapa tes dengan satu utas, mereka masih dapat menggunakan [Parallelizable(ParallelScope.None)] dan/atau OrderAttribute.

Masalah yang diterapkan ini akan memungkinkan untuk menjalankan suite pengujian lebih cepat dibandingkan dengan jaringan webdriver lokal atau penyedia Saas seperti BrowserStack atau SauceLabs. Saat ini saya mencoba membatasi jumlah metode pengujian pada kelas pengujian dengan jumlah node webdriver atau sesi browser yang tersedia, sehingga kisi digunakan sepenuhnya. Jika tidak, jika pengujian memiliki 8 metode pengujian dan kisi saya memiliki 8 sesi browser, hanya satu yang akan digunakan karena semua metode pengujian kelas akan dijalankan satu per satu.

@pablomxnl Sangat setuju. Sebagai pelatih atau pemimpin proyek, saya selalu mendorong gagasan itu dengan sangat keras. Namun, saya tidak memakai salah satu dari topi itu di sini. Saya penyedia perangkat lunak dengan pengguna yang meminta sesuatu. Jika mereka meminta hal-hal yang benar-benar mengerikan, saya hanya mengatakan tidak. Tetapi jika mereka meminta hal-hal yang masuk akal dalam beberapa konteks, tetapi tidak yang lain - bahkan tidak sebagian besar - saya mempertimbangkannya.

Dalam kasus situs web, kami hampir selalu tidak berbicara tentang pengujian unit. Tes fungsional tingkat yang lebih tinggi sering membutuhkan pengurutan. Apakah itu dilakukan melalui serangkaian langkah dalam pengujian atau serangkaian metode adalah detail implementasi bagi kami dan masalah kenyamanan bagi pengguna. Secara pribadi, saya pikir kita mungkin memerlukan sesuatu yang disebut [Langkah] yang berada di dalam kelas [StepFixture], atau beberapa nama yang serupa, sehingga kita dapat memindahkan semua hal pengurutan/pengurutan ini dari pengujian unit. Mungkin saya akan punya waktu untuk melakukannya sebelum web mati. :-)

Bagaimanapun, selalu menarik untuk mempelajari bagaimana orang benar-benar menggunakan perangkat lunak Anda.

@CharliePoole , tolong jangan salah

Sementara saya bisa berpura-pura memprediksi masa depan, itu hanya akan memuaskan Anda sampai September. :-)

Biarkan saya menjawab dengan menjelaskan bagaimana kami "menjadwalkan" fitur.

Kami sedang mencoba (sejak awal tahun) pendekatan yang rilisnya keluar sekali per kuartal. Saat kami menjadi lebih baik dalam melepaskan, kami dapat meningkatkan kecepatan. Akhirnya, kami mungkin dapat melakukan penyebaran berkelanjutan.

Dalam proyek Sumber Terbuka sukarela, tidak ada jumlah usaha tetap yang tersedia per bulan. Kita dapat menggunakan pendekatan "cuaca kemarin", tetapi ternyata jumlah waktu yang dihabiskan orang untuk NUnit, serta jumlah orang yang menjadi sukarelawan, cukup bervariasi.

Sebagai kompromi, kami memilih sejumlah kecil masalah yang merupakan kunci rilis dan menambahkannya ke pencapaian sebelumnya. Preferensi saya adalah menambahkan tidak lebih dari sekitar 25% dari apa yang mungkin kita harapkan untuk diselesaikan. Sebagian besar masalah dalam rilis hanya ditambahkan ke pencapaian tersebut setelah selesai atau paling baik ketika seseorang berkomitmen untuk mengerjakannya. Anda biasanya tidak akan menemukan masalah terbuka di tonggak 3,5 kami tanpa seseorang yang ditugaskan untuk itu, meskipun saya melakukannya sesekali jika sepertinya ada sesuatu yang menghalangi pekerjaan lain.

Jadi, sisi positif dari apa yang kami lakukan adalah kami hampir dapat menjamin bahwa rilis akan keluar tepat waktu. Sisi negatifnya adalah kami tidak dapat memberi tahu Anda apa yang akan ada di dalamnya. :-(

Untuk masalah khusus ini... Saya telah memberikannya prioritas tinggi untuk memberi tahu pengembang kami bahwa ini penting. Seseorang harus bebas mengerjakannya dan memiliki latar belakang yang cukup untuk proyek dengan cakupan dan kesulitan ini. Jika seseorang dengan latar belakang yang tepat mengambil ini dalam beberapa minggu ke depan, saya kira itu dapat dilakukan oleh rilis. Sebagai pedoman, saya pikir itu akan memakan waktu sekitar satu bulan, sambil mengerjakan beberapa hal lain juga, untuk menyelesaikan ini.

Maaf tidak ada jawaban yang lebih pasti tetapi jawaban seperti itu pasti bohong!

@CharliePoole apakah ada pembaruan yang mempertimbangkan fitur ini?

@tomersss kami belum mulai mengerjakan ini dan 3.5 mudah-mudahan akan keluar dalam beberapa minggu, jadi tidak mungkin di rilis berikutnya. Kami ingin fitur ini segera ditambahkan, tetapi minggu ini kami cukup sibuk mengatur ulang repositori dan basis kode kami. Ini ditandai dengan prioritas tinggi, jadi ada di radar kami.

@CharliePoole apakah ada pembaruan untuk masalah ini?

@KPKA kami belum mulai mengerjakan ini, jadi tidak ada pembaruan. Untuk pengguna yang menginstal ZenHub, Anda akan melihat masalah ini berpindah dari Backlog ke ToDo kemudian In Progress saat kami mulai mengerjakannya.

Untuk non-pengguna Zenhub, Anda akan dapat mengetahui kapan seseorang mengambilnya dengan melihat siapa yang ditugaskan untuk masalah tersebut.

@CharliePoole @rprouse

Hai!

Apakah ada berita tentang masalah ini?
Apakah itu akan di rilis berikutnya atau jika itu direncanakan di salah satu tonggak yang akan datang?

Saat ini adalah satu-satunya masalah yang mencegah kami beralih ke NUnit.
Akan lebih baik jika seseorang bisa mengakui dirinya untuk mulai mengerjakan ini dalam waktu dekat karena ada banyak orang yang terpengaruh, kurasa.

Berharap untuk mendengar dari Anda segera

@GitSIPA kerangka pengujian apa yang Anda gunakan yang memungkinkan Anda menjalankan metode pengujian secara paralel?

Untuk menjawab pertanyaan Anda, tidak ada yang mulai mengerjakan masalah ini, jadi tidak ada ETA, tetapi kami akan mempertimbangkan suara Anda saat kami memutuskan apa yang harus dikerjakan selanjutnya.

+1, Setuju dengan @GitSIPA. Ini adalah fungsi yang sangat penting

@GitSIPA +1
@rprouse Kami menggunakan mbunit, tetapi kerangka kerja ini tidak mendukung sekarang. Dan kami memiliki beberapa masalah dengan mbunit.

@rprouse Kami juga menggunakan MbUnit saat ini, tetapi karena dukungan tidak diberikan untuk versi Visual Studio yang baru, kami mempertimbangkan untuk beralih ke NUnit.

Pada edisi #1921 @jnm2 bertanya, "Apa yang berparameter secara paralel? Dapatkah saya berkontribusi?"

Pertanyaan kedua pertama: Pasti! Kami ingin bantuan Anda.

Dan untuk pertanyaan pertama:

1. Kami menjalankan "WorkItems", yang saat ini memetakan satu-ke-satu ke pengujian. Saya pikir kita perlu memperlakukan OneTimeSetUp dan OneTimeTearDown untuk fixture sebagai WorkItems terpisah sebagai langkah awal. Edisi #1096 membahas ini.

2. Kita perlu memiliki beberapa cara untuk membuat WorkItem bergantung pada WorkItem lain, sehingga hanya dijadwalkan untuk dieksekusi ketika semua item yang bergantung pada selesai. Saat ini kami melakukannya dengan cara yang sangat sederhana menggunakan CountDown tetapi kami membutuhkan sesuatu yang lebih umum. Penggunaan pertama dari ini, tentu saja, akan membuat OneTimeTearDown bergantung pada penyelesaian semua tes. Itu akan memiliki kegunaan lain nanti, ketika kami menerapkan ketergantungan di antara tes. Saya membayangkan ini sebagai antrian item kerja yang tertunda, tetapi mungkin ada cara lain untuk mengimplementasikannya.

3. Dengan tidak adanya dua hal tersebut, kita dapat mulai mengerjakan masalah utama itu sendiri: menjadwalkan pengujian untuk dijalankan daripada menjalankannya pada utas yang sama yang melakukan OneTimeSetUp untuk perlengkapan.

Jika Anda ingin mengerjakan ini, Anda harus sangat mengenal beberapa internal tentang bagaimana NUnit sebenarnya mengirimkan tes untuk dieksekusi. Saya akan dengan senang hati membantu Anda melakukannya.

Perencanaan apa yang sudah dilakukan selama ini?
Kebutuhan saya adalah menjalankan cukup banyak kasus TestCaseSource secara paralel untuk memenuhi CPU. Saya tidak memiliki persyaratan penyiapan, pembongkaran, atau pemesanan. Orang lain akan membutuhkan mereka untuk diperhitungkan sekalipun.

Saya berharap eksekusi TestCaseSource diparalelkan, jadi dua metode dalam perlengkapan yang sama yang menggunakan TestCaseSource berbeda akan mengeksekusi pencacahan secara paralel. Juga tampaknya akan lebih baik jika dua metode menggunakan TestCaseSource yang sama jika hanya dieksekusi sekali- pikirkan tentang ini?

Sunting: mengomentari KONDISI RACE. Kami sudah memulai dengan baik! 😆

Saya akan mengulangi cerita yang banyak saya ceritakan akhir-akhir ini. :senyum:

NUnit pertama-tama memuat tes (alias menemukan, mengeksplorasi) dan kemudian menjalankannya satu kali atau lebih, tergantung pada jenis pelari.

TestCaseSource Anda digunakan dalam pengujian pemuatan, bukan dalam menjalankannya, dan kami bahkan tidak menganggapnya sebagai bagian dari pengujian Anda - meskipun Anda mungkin memilikinya di kelas yang sama dengan pengujian Anda.

IOW, kasus pengujian Anda tidak "menggunakan" sumber kasus pengujian Anda, melainkan NUnit menggunakan sumber tersebut untuk membuat kasus pengujian. Tentu saja, mereka tidak dapat melakukan apa pun sampai dibuat. Masuk akal?

Seperti yang terjadi, pembuatan tes dari sumber dilakukan secara berurutan. Jika Anda memiliki beberapa kode yang dieksekusi di sumber yang membuatnya menjadi masalah, tebakan pertama saya adalah Anda melakukan terlalu banyak dalam sumber kasus uji. Misalnya, Anda tidak ingin membuat instance kelas di sumber kasus pengujian Anda, tetapi Anda ingin menyimpan parameter yang akan digunakan untuk membuatnya. Sayangnya, ini bisa menjadi satu bab buku. :senyum:

Jadi, masalah ini adalah __running__ test case secara paralel. Itu berarti semua kasus uji di bawah perlengkapan, kecuali Anda menandai beberapa sebagai tidak dapat diparalelkan. Sederhana, tes non-parameter serta kasus individu dari tes parameter akan diperlakukan sama dalam hal ini.

Ini akan menjadi eksperimen yang menarik untuk memungkinkan paralelisasi tes dalam perlengkapan di mana tidak ada OneTimeTearDown (saya pikir OneTimeSetUp tidak masalah). Ini mungkin berhasil dengan mudah jika Anda dapat membuat tekad itu dengan benar. Namun, penentuannya lebih sulit daripada yang Anda kira, karena OneTimeTearDown dapat menyertakan metode yang diwarisi dan ActionAttributes global.

@jnm2 Apakah Anda sudah memiliki kesempatan untuk mengatasi masalah khusus ini?

@julianhaslinger Tidak. Itu ada dalam daftar saya setelah dua masalah saya yang lebih mendesak, 1885 dan 1933. Jika Anda ingin mengatasinya, lebih baik!

@julianhaslinger Karena kita tidak mengenal satu sama lain, mohon maafkan saya karena mengatakan bahwa ini adalah hal yang sulit untuk https://github.com/nunit/nunit/issues/164#issuecomment -265267804 untuk perincian menjadi PR terpisah yang ingin saya lihat untuk memperbaikinya. Jika Anda menemukan pendekatan yang lebih sederhana, posting tentang itu sebelum mengkodekannya, sehingga kami dapat menimbang pertimbangan masa depan terhadap YAGNI yang jelas terlibat dalam memprediksi masa depan.

@CharliePoole @jnm2 Hai teman-teman!

Bukannya saya ingin mulai mengimplementasikan fitur yang hilang ini, tetapi hanya untuk mengetahui perkembangannya. Seperti yang saya tahu dari jawaban Anda (di atas), belum ada kemajuan (?) terkait permintaan fitur khusus ini.

@CharliePoole Salah satu masalah potensial yang saya temui saat meneliti kode adalah bagaimana Fixtures ditangani sekarang. Saat ini semua WorkItems memiliki akses ke instance Fixture yang sama , yang berarti bahwa jika WorkItems dieksekusi secara paralel, mereka akan mengakses satu instance dari kelas pengujian. Ini bermasalah karena kondisi balapan yang dibuatnya saat pengujian mengandalkan Setup atau Teardown untuk menyetel bidang level instans.

Salah satu solusi untuk ini adalah membuat setiap WorkItem beroperasi pada instance baru dari kelas pengujian, tetapi ini kemungkinan akan memperumit perilaku pengaturan Fixture karena tidak akan ada lagi satu instance fixture

@chris-smith-zocdoc Ya, itulah perbedaan terbesar antara NUnit dan junit pendahulunya. Kembali pada hari itu, itu dibahas secara luas pro dan kontra tetapi tidak banyak muncul sekarang. Oleh karena itu, pengujian NUnit seharusnya tidak memiliki status, dengan semua inisialisasi dilakukan dalam metode SetUp.

Setelah TestFixtureSetUp (sekarang disebut OneTimeSetUp) diperkenalkan, menjadi mungkin untuk melakukan inisialisasi yang lebih mahal sekali dan semua pengujian beroperasi pada nilai inisialisasi yang sama. Ini paling berguna saat membuat instance dari kelas yang sedang diuji, yang mungkin stateful. Dalam beberapa tahun terakhir, semakin banyak pengguna yang memanfaatkan kemampuan ini.

Subjek penambahan opsi untuk membuat instance terpisah dari perlengkapan pengguna per kasus uji muncul secara berkala. Sejauh ini, belum sampai ke tahap menjadi fitur yang direncanakan. Ini pasti terkait dengan kegunaan fitur metode paralel di pihak pengguna, tetapi saya pikir itu ortogonal dengan implementasinya. JIKA kami membuat perlengkapan baru per instance, kami hanya akan menjalankan penyiapan "satu" kali lebih dari sekali. Tentu saja, itu akan memukul keras setiap pengguna yang menggunakan statika. 😢

Kami menunda metode pengujian paralel karena dua alasan: (1) sulit untuk diterapkan dan (2) tampaknya perlengkapan paralel, meskipun lebih mudah bagi kami, sudah cukup bagi sebagian besar pengguna. Sangat sedikit pengguna yang tampaknya berbagi status di beberapa perlengkapan saat muncul (berdasarkan diskusi online) banyak pengguna berbagi status di seluruh metode pengujian. Sejauh ini, banyak pengguna memanfaatkan paralelisme yang ada dan sementara beberapa sangat menginginkan paralelisme metode, mereka tampaknya merupakan kelompok yang relatif kecil.

Namun demikian, saya kira sudah waktunya untuk melakukan sesuatu. Saya akan melakukan ini untuk kuartal pertama, setidaknya sejauh menjalankan beberapa eksperimen dan mungkin menghasilkan perincian tugas yang masuk akal yang dapat ditindaklanjuti orang lain.

JIKA kami membuat perlengkapan baru per instance, kami hanya akan menjalankan penyiapan "satu" kali lebih dari sekali. Tentu saja, itu akan memukul keras setiap pengguna yang menggunakan statika.

Saya pikir masuk akal untuk mengharuskan tidak ada keadaan statis jika Anda memilih untuk berjalan secara paralel, sejauh itu adalah kesalahan Anda jika ada yang rusak karena mencampur keadaan statis dan paralelisme. Untungnya semua kode Anda akan diuji sehingga akan sulit untuk dilewatkan

Namun demikian, saya kira sudah waktunya untuk melakukan sesuatu. Saya akan melakukan ini untuk kuartal pertama, setidaknya sejauh menjalankan beberapa eksperimen dan mungkin menghasilkan perincian tugas yang masuk akal yang dapat ditindaklanjuti orang lain.

Hitung saya untuk itu.

Gerakan mengungkap kekerasan seksual demi menghapuskannya!

Pada Sabtu, 14 Jan 2017 jam 3:58, Joseph Musser [email protected]
menulis:

>
>
>
>

[gambar: Boxbe] https://www.boxbe.com/overview

Pembersihan Otomatis: simpan 1 email terakhir ([email protected])

Sunting aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D&tc_serial=28420100882&tc_rand=128339648&utm_source=stf&utm_medium=email&utm_content=email&utm_ED

| Hapus aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D&tc_serial=28420100882&tc_rand=128339648&utm_source=stf&utm_medium=email&utm_content=email&utm_ED

| Tandai penting
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D%26important%3Dtrue%26emlId%3D54854949581&tc_serial=28420100882&tc_rand=1282&tc_rand=1282

JIKA kami membuat perlengkapan baru per instance, kami hanya akan menjalankan "satu"
pengaturan waktu lebih dari sekali. Tentu saja, itu akan memukul keras setiap pengguna yang
memanfaatkan statika.

Saya pikir masuk akal untuk mengharuskan tidak ada keadaan statis jika Anda
memilih untuk berjalan secara paralel, sejauh itu salahmu jika sesuatu
istirahat untuk mencampur keadaan statis dan paralelisme. Untungnya semua kode ini akan
sedang diuji jadi pasti sulit untuk dilewatkan :D

Namun demikian, saya kira sudah waktunya untuk melakukan sesuatu. Aku akan mengambil ini
untuk kuartal pertama, setidaknya sejauh menjalankan beberapa eksperimen
dan mungkin menghasilkan perincian tugas yang masuk akal yang bisa dilakukan orang lain
menindaklanjuti.

Hitung saya untuk itu.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-272488655 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AAHNVlwVps8pQ93UIwZw6zY7TOyHO0a6ks5rR61EgaJpZM4CUZ8r
.

Menjalankan beberapa tes waktu, saya menemukan sesuatu yang menarik. Ada ambiguitas dalam menyebut kasus uji dapat diparalelkan. Ini mungkin juga berlaku untuk perlengkapan dan suite lainnya, tetapi kurang jelas.

Begini masalahnya: jika suatu metode benar-benar tidak dapat diparalelkan, itu berarti ia tidak dapat berjalan secara paralel dengan __metode lain__. OTOH, jika hanya non-paralelizable di dalam fixturenya maka tidak dapat berjalan secara paralel dengan __metode lain di fixture yang sama.__

Saya mengusulkan kami menangani perbedaan ini sebagai berikut:

1. Jika metode pengujian tidak memiliki atribut Parallelizable, metode tersebut harus dijalankan pada utas yang sama dengan perlengkapan yang memuatnya, asalkan tidak ada atribut lain (mis. Apartemen) yang memintanya untuk dijalankan pada utas yang berbeda

2. Jika memiliki atribut Parallelizable dengan cakupan Self, atau jika suite tingkat yang lebih tinggi menentukan cakupan Anak, maka metode pengujian dijalankan secara paralel dengan metode lain di fixture.

Pikiran @nunit/core-team ?

Ditinggalkan di atas:

1. Jika memiliki atribut Parallelizable dengan cakupan None, maka ia berjalan pada antrian non-paralel.

@CharliePoole - tiga poin Anda masuk akal, meskipun saya tidak jelas tentang alternatif apa yang Anda sarankan agar kami tidak melakukannya. Bisakah Anda mengklarifikasi?

Saat ini kami memperlakukan tidak memiliki atribut yang sama dengan memilikinya dengan ParallelScope.None. Itu membuat mereka mengantri di antrian non-paralel jika saya mengaktifkan pengiriman mereka dan uji coba melambat secara signifikan.

PR #2011 mengambil beberapa langkah awal untuk mengimplementasikan fitur ini tetapi berisi #define yang memaksa test case untuk berjalan di thread perlengkapan yang berisi mereka. Komentar ini mendokumentasikan apa yang menurut saya perlu dilakukan untuk menghilangkan batasan itu.

Saat ini, OneTimeTearDown perlengkapan berjalan di utas yang digunakan untuk menyelesaikan kasus uji terakhir yang dieksekusi. Jika test case berjalan secara paralel, kami tidak dapat memprediksi test case yang mana. Ini mungkin utas dengan karakteristik berbeda dari yang diperlukan untuk perlengkapan. Misalnya, jika tes terakhir yang harus diselesaikan berjalan di STA, itulah yang akan digunakan untuk menjalankan OneTimeTearDown, bahkan jika OneTimeSetUp berjalan di MTA. Dalam banyak kasus, itu mungkin tidak menyebabkan masalah, tetapi dalam beberapa kasus bisa.

Ini mungkin sebenarnya menjadi masalah dengan perlengkapan tingkat yang lebih tinggi juga, tetapi pengenalan kasus uji paralel berarti akan ada lebih banyak peluang untuk ketidakcocokan yang menyebabkan kesalahan.

Jadi, untuk memastikan bahwa pembongkaran perlengkapan terjadi pada jenis utas yang tepat, kami tidak dapat lagi menjalankannya di utas tes terakhir yang akan dijalankan. Sebagai gantinya, petugas operator perlu menyimpan informasi tentang semua teardown yang tertunda dan diberi tahu untuk menjalankan teardown tersebut di utas yang tepat pada waktu yang tepat. Mencari tahu bagaimana melakukannya adalah fase "desain" dari fitur ini.

untuk siapa saja yang telah mengikuti utas ini sejak awal (pada tahun 2014) dan tidak ingin atau tidak dapat menerapkan solusi mereka sendiri sambil menunggu penambahan fitur ini, saya baru saja menemukan implementasi menggunakan NUnit 2.6.3 yang tersedia di CodePlex yang tampaknya cukup mudah digunakan (Saya telah memverifikasi bahwa ini berfungsi dalam menjalankan pengujian fungsional kami di beberapa utas paralel).

http://cpntr.codeplex.com/

maaf sebelumnya @CharliePoole jika pesan ini agak ortogonal dengan diskusi baru-baru ini di utas ini, tetapi jika ada orang lain yang telah menunggu 3 tahun terakhir untuk penambahan fitur ini berdasarkan janji yang ditetapkan untuk NUnit 3 (jauh di awal hari), saya pikir itu mungkin menawarkan solusi sampai kalian berhasil menyelesaikan masalah desain (terdengar seperti Anda mendekati solusinya).

@CharliePoole

Jadi, untuk memastikan bahwa pembongkaran perlengkapan terjadi pada jenis utas yang tepat, kami tidak dapat lagi menjalankannya di utas tes terakhir yang akan dijalankan. Sebagai gantinya, petugas operator perlu menyimpan informasi tentang semua teardown yang tertunda dan diberi tahu untuk menjalankan teardown tersebut di utas yang tepat pada waktu yang tepat. Mencari tahu bagaimana melakukannya adalah fase "desain" dari fitur ini.

Apakah kami memerlukan petugas operator untuk mengetahui item teardown yang tertunda di muka, atau dapatkah kami mengirimkannya saat tersedia? Lebih konkretnya, di mana CompositeWorkItem saat ini memanggil PerformOneTimeTearDown, bisakah kita menggunakan operator untuk mengirim unit kerja baru ke shift kerja yang benar?

@chris-smith-zocdoc Ya, itulah yang saya lakukan. Saya membuat item pekerjaan jenis baru, OneTimeTearDownWorkItem , yang bersarang di CompositeWorkItem dan dikirim saat tes anak terakhir dijalankan. Nanti, kita mungkin melihat beberapa efisiensi ketika OneTimeSetUp dan semua tes telah dijalankan di thread yang sama.

Belum membaca semuanya terlalu hati-hati, tetapi satu hal yang ingin saya minta sebagai bagian dari fitur ini adalah paralelisme menjadi "pintar", terutama untuk tes terikat I/O. Misalnya, jika Anda memiliki 10 utas yang menjalankan 100 pengujian yang dapat diparalelkan, seharusnya 10 utas tersebut tidak duduk dan menunggu hingga 10 pengujian pertama selesai sebelum melanjutkan ke 10 pengujian berikutnya. Jika 10 tes pertama mulai menunggu tugas I/O yang berjalan sangat lama, maka utas harus bebas untuk beralih ke tes lain. Saat tugas I/O selesai, utas akan melanjutkan pengujian yang menunggu saat utas dikosongkan.

Pada dasarnya, saya meminta manajemen throughput yang cerdas untuk tes terikat I/O yang menggunakan async/menunggu secara ekstensif. Ini adalah hambatan nomor satu kami dalam pengujian, sejauh ini.

@chris-smith-zocdoc Sebenarnya, itulah yang saya lakukan. Saya pada dasarnya menggunakan mekanisme hitung mundur yang ada untuk memicu pengiriman tugas pembongkaran satu kali. Triknya adalah mengirimkannya pada antrian yang tepat.

@gzak Ingatlah bahwa mekanisme untuk eksekusi paralel sudah ada. Itu tergantung pada pekerja yang secara mandiri menarik tugas daripada memiliki pengontrol yang mendorong tugas ke pekerja. Jadi jika satu pekerja sibuk dengan suatu tugas untuk sementara waktu, pekerja lain akan terus melakukan tugas lainnya secara mandiri. Caranya adalah dengan mengatur jumlah pekerja berdasarkan sifat tes yang dijalankan. NUnit bekerja dengan cukup baik secara default dengan tes unit yang terikat komputasi normal tetapi jenis tes lain mungkin mengharuskan pengguna mengatur tingkat paralelisme yang sesuai.

Dapatkah seseorang menjelaskan kepada saya bagaimana cara kerjanya?
Saya memiliki kelas ujian
Ketika saya menjalankan tes di kelas ini TIDAK secara paralel - semua tes lulus
Tetapi ketika saya menjalankannya dengan [Parallelizable(ParallelScope.Children)]
Jadi mereka berjalan secara paralel (beberapa metode di kelas yang sama)
tetapi untuk beberapa alasan beberapa tes gagal.
Saya memiliki bidang instance di kelas ini yang digunakan di seluruh pengujian dan tampaknya bidang tersebut dibagikan di antara utas
Apakah saya benar?
Apakah Anda hanya membuat 1 instance dari kelas itu dan memanggil metode secara bersamaan pada objek tunggal ini?
CharlieKolam Renang

Anda mengetahuinya! Ya, semua pengujian di fixture menggunakan instance yang sama. Ini adalah sejarah dengan NUnit, yang selalu bekerja seperti itu. Anda harus memilih antara menjalankan kasus uji secara paralel dan memiliki status apa pun yang dimodifikasi per pengujian. Tidak ada jalan lain saat ini.

Yang mengatakan, jika Anda memiliki proporsi perlengkapan yang layak, menjalankan perlengkapan secara paralel dapat memberi Anda kinerja yang baik.

Apakah mungkin untuk memiliki [Parallelizable(ParallelScope.Children)] di
File AssemblyInfo.cs?

Apakah ada yang melihat itu bekerja?

Pada 14 Juni 2017 pukul 01:37, CharliePoole [email protected] menulis:

[image: Boxbe] https://www.boxbe.com/overview Pembersihan Otomatis: keep
1 email terakhir ([email protected]) Edit aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D&tc_serial=30872123699&tc_rand=2087335475&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| Hapus aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D&tc_serial=30872123699&tc_rand=2087335475&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| Tandai penting
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D%26important%3Dtrue%26emlId%3D61187554820&tc_serial=30872123699&tc_rand=2087335475&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001

Anda mengetahuinya! Ya, semua pengujian di fixture menggunakan instance yang sama.
Ini adalah sejarah dengan NUnit, yang selalu bekerja seperti itu. Kamu harus
memilih antara menjalankan kasus uji secara paralel dan memiliki status apa pun yang
dimodifikasi per tes. Tidak ada jalan lain saat ini.

Yang mengatakan, jika Anda memiliki proporsi perlengkapan yang layak, jalankan saja
perlengkapan secara paralel dapat memberi Anda kinerja yang baik.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308157832 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AAHNVuK-J-X74mlAA_eT7OX7dxs7MpoRks5sDqzLgaJpZM4CUZ8r
.

@agray Ya, sebenarnya itulah satu-satunya alasan saya memiliki AssemblyInfo.cs sekarang.

Hai Yusuf,

Baris paralelisme apa yang Anda tambahkan ke file AssemblyInfo.cs Anda?

Saya ingin tahu apa yang berhasil.

Bersulang,

Andrew

Pada hari Rabu, 14 Jun 2017 jam 16.17, Joseph Musser [email protected]
menulis:

[image: Boxbe] https://www.boxbe.com/overview Pembersihan Otomatis: keep
1 email terakhir ([email protected]) Edit aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D&tc_serial=30882364582&tc_rand=1974513896&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| Hapus aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D&tc_serial=30882364582&tc_rand=1974513896&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| Tandai penting
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D%26important%3Dtrue%26emlId%3D61214070592&tc_serial=30882364582&tc_rand=1974513896&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001

@array https://github.com/array Ya, sebenarnya itulah satu-satunya alasan saya
memiliki AssemblyInfo.cs sekarang.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308325726 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AAHNVghNAX8CJkqAy-qhAz8bXNhZcFOQks5sD3NigaJpZM4CUZ8r
.

@agray Yang Anda tanyakan:

c# [Parallelizable(ParallelScope.Children)]

jangan lupa targetnya

[assembly: Parallelizable(ParallelScope.Children)]

@LirazShay Saya menggunakan NUnit untuk mendorong tes Selenium, dan menggunakan bidang tingkat perlengkapan untuk menyimpan hal-hal seperti referensi ke akun pengguna dan ke contoh Selenium WebDriver yang saya kerjakan sehingga tidak dapat menjalankan tes secara paralel dalam perlengkapan. Cara saya mengatasinya adalah dengan menulis "pabrik" (saya menggunakan tanda kutip karena saya tidak yakin itu istilah yang tepat) yang mengimplementasikan IDisposable yang untuk setiap pengujian merangkum semua kebutuhan pengujian saya dan dengan bersih meruntuhkannya di akhir tes tanpa perlu [TearDown] atau [OneTimeTearDown] seperti:

 public class TestFactory : IDisposable
    {
    // Instantiate a new SafeHandle instance.
    private readonly System.Runtime.InteropServices.SafeHandle handle = new Microsoft.Win32.SafeHandles.SafeFileHandle(IntPtr.Zero, true);

    // Flag: Has Disposed been called?
    private bool disposed = false;

    public TestFactory()
    {
        this.UserRepository = new List<UserAccount>();
        this.DU = new DataUtility();
    }

    // A list of users created for this test
    public List<UserAccount> UserRepository { get; private set; }

    // A very simple data layer utility that uses Dapper to interact with the database in my application 
    public DataUtility DU { get; private set; }

    // Gets a new user and adds it to the repository
    public UserAccount GetNewUser()
    {
        var ua = new UserAccount();
        this.UserRepository.Add(ua);
        return ua;
    }


    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed)
        {
            return;
        }

        if (disposing)
        {
            // Deletes all user accounts created during the test
            foreach (UserAccount ua in this.UserRepository)
            {
                try
                {
                    ua.Delete();
                }
                catch (Exception)
                {
                    // Take no action if delete fails.
                }
            }

            this.DU.DeleteNullLoginFailures(); // Cleans up the database after tests
            Thread.Sleep(1500);
        }

        this.disposed = true;
    }
}

Kemudian, dalam tes saya bisa melakukan ini:

[TestFixture]
public class UserConfigureTests
{
    [Test]
    public void MyExampleTest()
    {
        using (TestFactory tf = new TestFactory())
        {
            var testUser = tf.GetNewUser();

    tf.DU.DoSomethingInTheDatabase(myParameter);

    // Test actions go here, and when we exit this using block the TestFactory cleans
    // up after itself using the Dispose method which calls whatever cleanup logic you've written into it
        }
    }
}

Dengan cara ini, saya dapat menghindari banyak duplikasi kode, dan jika saya perlu mengubah dependensi pengujian saya, saya hanya melakukannya sekali di pabrik. Jika ada yang memiliki umpan balik tentang strategi yang saya ambil, saya akan menghargainya!

@tparikka Saya sangat merekomendasikan pendekatan itu sendiri.

Saya memiliki yang berikut ini di file AssemblyInfo saya:

[perakitan: Parallelizable(ParallelScope.Children)]
[perakitan: LevelOfParallelism(16)]

Apakah saya memerlukan atribut LevelOfParallelism juga lagi?

Pada 15 Juni 2017 pukul 04:37, Joseph Musser [email protected] menulis:

[image: Boxbe] https://www.boxbe.com/overview Pembersihan Otomatis: keep
1 email terakhir ([email protected]) Edit aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D&tc_serial=30894750852&tc_rand=1847060911&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| Hapus aturan
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D&tc_serial=30894750852&tc_rand=1847060911&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001
| Tandai penting
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D%26important%3Dtrue%26emlId%3D61245244440&tc_serial=30894750852&tc_rand=1847060911&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_EDIT&utm_content=001

@tparikka https://github.com/tparikka Saya sangat merekomendasikan hal itu
mendekati diriku.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/nunit/nunit/issues/164#issuecomment-308521058 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/AAHNVmEzVDbw32Xx0jkYcGK9bZW3tLvXks5sECh8gaJpZM4CUZ8r
.

Saya belum melihat penggunaan LevelOfParallelism . Ini default ke jumlah core yang Anda miliki.

Jika pengujian Anda tidak terikat CPU, lebih tinggi masuk akal. Tetapi seperti biasa dengan perf- jawabannya sangat tergantung pada skenario Anda sehingga lebih baik mengukur daripada menebak.

@CharliePoole Saya menggunakan TestcaseSource , tetapi sepertinya testcase yang dihasilkan tidak benar-benar dieksekusi secara paralel. Apakah sesuatu seperti ini diharapkan berfungsi:

```c#
[Perlengkapan Tes]
Deserialisasi kelas
{
IEnumerable statis publikShouldDeserializeAllCases() => Enumerable.Repeat(0, 5).Select(x => TimeSpan.FromSeconds(2));

    [TestCaseSource("ShouldDeserializeAllCases"), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t)
    {
        Thread.Sleep(t);
        Assert.AreEqual(1, 1);
    }
}

```

Waktu keseluruhan yang diambil adalah 10 detik, bukan ~2.

Saya akan berpikir bahwa tidak ada anak-anak, jadi dalam hal ini, Anda sebaiknya menggunakan
[Parallelizable(ParallelScope.All)]
atau pindahkan atribut Anda di tingkat kelas.

@ParanoikCZE Terima kasih. Saya benar-benar terbang buta sehubungan dengan apa arti atribut itu, jadi saya sudah mencoba semua nilai enum di sana. Terlepas dari All , Children , Fixture atau Self saya gunakan, saya mendapatkan waktu eksekusi 10 detik (setidaknya di Visual Studio).

Saya baru saja mencoba memindahkannya ke kelas, tetapi ini sepertinya juga tidak membantu.

Coba ini sumber inspirasi :)

class Deserialization
{
    public static IEnumerable<TestCaseData> ShouldDeserializeAllCases
    {
        get
        {
            for (int i = 1; i <= 5; i++)
                yield return new TestCaseData(TimeSpan.FromSeconds(i)).SetName($"Thread_worker_{i}");
        }
    }

    [TestCaseSource(nameof(ShouldDeserializeAllCases)), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t) => System.Threading.Thread.Sleep(t);
}

@ParanoikCZE Terima kasih lagi. Saya menguji ini di Visual Studio dan visualisasinya jauh lebih jelas, tetapi tesnya masih berjalan secara berurutan. Lebih mudah untuk melihat ini jika Anda menggunakan sleep konstan untuk setiap testcase daripada meningkatkan langkah.

Coba tambahkan [assembly: LevelOfParallelism(5)] ke dalam AssemblyInfo, saya pikir ada beberapa nilai default, tapi mungkin entah bagaimana itu tidak berhasil untuk Anda. Pokoknya aku kehabisan ide. :)