Nunit: Tes Unit Gagal di nunit.framework.tests Setelah Klon Baru

Dibuat pada 25 Jun 2018 · 31Komentar · Sumber: nunit/nunit

Saya baru saja mengambil klon baru dari nunit dan membuka solusi di Visual Studio 2017 (Komunitas 15.7.4) dengan Adaptor Uji NUnit 3 terbaru (3.10 dengan Jalankan Tes secara Paralel) yang berjalan pada Windows 10 Professional dan memilih "Debug-AnyCPU " dan tekan build.

Setelah membaca BUILDING.md sepertinya saya harus mengabaikan kegagalan yang tidak berasal dari nunit.framework.tests-* dan nunitlite.tests-*

Namun di luar gerbang saya mendapatkan 2 kegagalan dari nunit.framework.tests-*

Kesalahan Pertama:

Test Name:  TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test FullName:  NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory("C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20")
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs : line 110
Test Outcome:   Failed
Test Duration:  0:00:00.001

Result StackTrace:  at NUnit.Framework.TestContextTests.TestCaseSourceCanAccessWorkDirectory(String workDirectory) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\TestContextTests.cs:line 112
Result Message: 
Expected string length 34 but was 50. Strings differ at index 34.
  Expected: "C:\\Users\\ace.olszowka\\source\\nunit"
  But was:  "C:\\Users\\ace.olszowka\\source\\nunit\\bin\\Debug\\net20"
  -------------------------------------------------^

Melihat sumbernya, saya tidak melihat bagaimana ini mungkin, sejauh yang saya tahu nilai-nilai ini seharusnya identik ( _workDirectory dan data pengujian keduanya disetel ke TestContext.CurrentContext.WorkDirectory ) satu-satunya kira adalah beberapa jenis kondisi balapan, mungkin karena konfigurasi yang buruk di pihak saya?

Kesalahan Kedua:

Test Name:  StackTracesAreFiltered("WarningInBeginInvoke",4)
Test FullName:  NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered("WarningInBeginInvoke",4)
Test Source:    C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs : line 292
Test Outcome:   Failed
Test Duration:  0:00:00.004

Result StackTrace:  at NUnit.Framework.Assertions.WarningTests.StackTracesAreFiltered(String methodName, Int32 maxLineCount) in C:\Users\ace.olszowka\source\nunit\src\NUnitFramework\tests\Assertions\WarningTests.cs:line 310
Result Message: 
Multiple failures or warnings in test:
  1) (Warning message)
  2) Expected the number of lines to be no more than 4, but it was 5:

 1. at NUnit.TestData.WarningFixture.<>c__DisplayClass45_0.<WarningInBeginInvoke>b__0()
 2. at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
 3. at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
 4. at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
 5. at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
(end)

Saya tersesat dalam apa yang coba dilakukan tes ini di sini; tetapi berdasarkan pemahaman saya yang terbatas sepertinya kode ini sangat sensitif terhadap perubahan apa pun dalam tumpukan panggilan, mungkinkah ini karena perubahan terbaru di .NET Framework?

Saya juga mendapatkan setiap kasus uji gagal di NUnitLite.Tests.CommandLineTests Saya akan dengan senang hati menggali di sana jika ini tidak terduga.

Melihat build lewat di CI, ini mungkin hanya masalah konfigurasi di pihak saya, tetapi tidak ada yang disebutkan di BUILDING.md tentang ini, jadi saya pikir laporan itu sepadan.

bug normal

Sumber

aolszowka

👍1

Semua 31 komentar

Terima kasih atas laporannya! Saya telah mengonfirmasi bahwa TestCaseSourceCanAccessWorkDirectory dan CommandLineTests tidak berfungsi di Test Explorer. Kita perlu menemukan cara untuk membuat mereka independen dari pelari dan paralelisme. @nunit/framework-team Ada ide?

Untuk kesalahan kedua, itu adalah tes bau. Masuk akal untuk menambahkannya ke 5.

jnm2 pada 2 Jul 2018

👍1

Di masa lalu, saya hanya mengatakan kepada orang-orang untuk tidak menggunakan test explorer untuk tes NUnit. Anggota tim lain menentang pernyataan bahwa penjelajah uji telah menjadi, bagi banyak orang, cara default untuk menjalankan pengujian.

Tentu saja ada banyak preseden untuk pelari tertentu yang tidak berguna saat menguji kerangka kerja pengujian. Kerangka pengujian yang sedang diuji adalah situasi yang cukup khusus dan tidak dihadapi oleh sebagian besar pengguna. OTOH, jika tim menginginkan, mungkin Anda akan menjadikannya tujuan untuk dapat berhasil menjalankan explorer pengujian melalui adaptor.

Apa pun yang Anda lakukan, saya pikir Anda mungkin harus mengeluarkan beberapa dokumentasi yang memberi tahu orang-orang bahwa menjalankan tes NUnit di bawah test explorer saat ini tidak berfungsi. Anda dapat memberi tahu mereka dalam konteks itu bahwa itu adalah tujuan untuk membuatnya bekerja atau itu bukan prioritas, mana pun yang diputuskan.

Sebagai penulis pertama adaptor dan kontributor bertahun-tahun untuk kerangka kerja, saya selalu mencela penggunaan penjelajah uji dalam pengembangan NUnit. Itu masih pandangan saya tentang masalah ini. Heck, saya bahkan tidak suka kita menggunakan konsol untuk menguji kerangka kerja di CI kita sekarang!!!

Apa pun keputusannya, saya pikir Anda harus terus mengirim orang kembali ke runner NUnit yang sebenarnya (baik NUnitLite atau runner konsol) ketika masalah muncul yang mungkin atau mungkin bukan karena adaptor. Adaptor pada dasarnya tetap setara dengan runner pihak ketiga, meskipun berada di bawah Proyek NUnit.

CharliePoole pada 2 Jul 2018

👍1

FWIW dari luar melihat ke dalam: Tidak masalah bagi saya ke mana ia memotong selama itu didokumentasikan seperti itu.

Di luar kotak, saya sebagai pengembang akan mencoba melakukan apa yang biasanya saya lakukan ketika saya menemukan proyek baru yang menggunakan praktik yang sama dengan yang saya gunakan secara internal:

Kloning Kode
Baca README.md/BUILD.md/HACKING.md
Mencoba Membangun (tanpa perubahan)
Jalankan Tes Unit (melalui Runner terintegrasi).
Jika semuanya berhasil, mulailah bermain dengan barang-barang.

Di masa lalu ini akan menjadi dotCover ReSharper tetapi kami telah mencoba untuk menghentikannya karena biaya lisensi hanya gila untuk toko kecil/pengembang individu ketika ada Alternatif Perangkat Lunak Sumber Terbuka Gratis yang "kebanyakan berfungsi".

Ada banyak (menurut saya) konsep Lingkungan Pengembangan Terpadu, tidak harus keluar dari alur kerja sangat berguna itulah sebabnya kami melakukannya.

Namun jika kita diharapkan menggunakan Console Runner (atau Runner lainnya) menurut saya tidak masalah, dokumentasikan saja.

aolszowka pada 2 Jul 2018

Jika Anda mengembangkan di NUnit, mengerjakan kerangka kerja, saya pikir pencampuran di setiap pelari yang melakukan hal-hal dengan cara khusus (R#, adaptor kami sendiri) dapat membingungkan masalah. Saya ingin tahu bahwa kerangka kerja bekerja dengan benar dalam isolasi sebelum mengujinya dengan pelari. Jadi dalam pekerjaan saya sendiri, saya menggunakan nunitlite untuk menguji saat saya mengembangkan dan kemudian menjalankan CI secara lokal. Jika seseorang ingin mengembangkan NUnit di Test Explorer, saya akan mengatakan mereka harus tetap menjalankan CI secara lokal dan juga harus kembali ke nunitlite atau nunit3-console ketika ada yang terlihat cerdik.

Untuk orang-orang yang hanya menjalankan tes nunit dari rilis tertentu, saya pikir ada lebih banyak lintang.

CharliePoole pada 2 Jul 2018

Kita harus membuat CI kanonik, mungkin dengan NUnitLite untuk semua pengujian kerangka kerja dan kemudian Konsol, adaptor VSTest, dan runner UWP untuk pengujian ujung ke ujung.

Dengan asumsi CI solid, sepertinya tidak masalah bagi saya jika ada perbedaan halus antara Test Explorer, ReSharper, NCrunch, dan skrip CI kami. Mengatakan alat dalam-IDE ini harus diabaikan adalah sesuatu yang saya lihat sebagai penghalang untuk berkontribusi dan salah karena itu bahkan bukan alur kerja saya. Alur kerja ideal saya:

Temukan tes yang ada atau tulis tes baru
Sematkan perlengkapan tes itu untuk membuatnya cepat menjalankan kembali tes saat mengetik (lebih baik lagi, mulai pengujian berkelanjutan)
Menerapkan perubahan
Sebelum membuat komit Git, jalankan .\build.ps1 -t test untuk memastikan lolos dan gagal seperti yang diharapkan
Jika ada kejutan, temukan dan sematkan tes yang terpengaruh yang tidak saya ketahui dan lanjutkan ke langkah 3

Dalam skenario langka di mana tes sensitif terhadap pelari, saya tidak yakin akan sulit untuk membuatnya tidak sensitif terhadap pelari. Itu tidak bisa lebih buruk daripada tes integrasi yang saya tulis untuk ILMerge yang saya buat tahan terhadap salinan bayangan ReSharper dan NCrunch.

jnm2 pada 2 Jul 2018

@aolszowka Saya 100% setuju dengan pendapat Anda bahwa apa pun yang kita lakukan, kita harus menghormati waktu kontributor dengan menjaga agar dokumen kontribusi mudah dikonsumsi dan mutakhir.

jnm2 pada 2 Jul 2018

@ jnm2 Saya suka pendekatan "kanonik" Anda. Saya ragu akan mudah untuk membuat semuanya bekerja dengan lancar di Test Explorer, tetapi patut dicoba.

Ini masih berguna, penting, bagi siapa saja yang bekerja di nunit untuk mengetahui kapan harus beralih ke tingkat pengujian yang lebih rendah.

Hal terbesar yang dapat kami lakukan untuk memajukan ide ini IMO adalah membangun sistem terpisah dan mungkin tes integrasi.

CharliePoole pada 2 Jul 2018

👍1

Ini mungkin akar penyebabnya. Saat menulis tes untuk mendapatkan XML dari FrameworkController, saya perhatikan bahwa TestContext.WorkDirectory diubah menjadi C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE :

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/Api/DefaultTestAssemblyBuilder.cs#L137

Tumpukan panggilan:

>   nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(System.Reflection.Assembly assembly, string suiteName, System.Collections.Generic.IDictionary<string, object> options) Line 137    C#
    nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> options) Line 114    C#
    nunit.framework.dll!NUnit.Framework.Api.NUnitTestAssemblyRunner.Load(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> settings) Line 154   C#
    nunit.framework.dll!NUnit.Framework.Api.FrameworkController.LoadTests() Line 204    C#

Itu karena TestContext.WorkDirectory adalah status statis yang bisa berubah:

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/TestContext.cs#L96 -L101

Itu berarti itu dibagikan oleh semua tes (!), termasuk yang bersamaan. Tes apa pun yang bergantung pada WorkDirectory harus ditandai [NonParallelizable] agar benar.

jnm2 pada 14 Jul 2018

Saya mencatat masalah ini sejak lama. Ada masalah tentang itu di suatu tempat.

NonParallelizable tidak cukup. Jika ada pengujian yang mengubah WorkDirectory (seperti yang dilakukan oleh banyak pengujian NUnit), ada kemungkinan yang masuk akal bahwa pengujian lain yang mengandalkannya akan gagal.

Itu semua tergantung pada urutan pengujian dijalankan, yang tidak ditentukan dalam NUnit.

oznetmaster pada 14 Jul 2018

Tujuannya adalah bahwa direktori Kerja harus ditetapkan sekali dan tetap tidak berubah untuk dijalankan. Apa lagi US bug.

CharliePoole pada 14 Jul 2018

Apakah ada alasan mengapa kami tidak mengizinkan direktori kerja independen untuk setiap konteks eksekusi?

@CharliePoole Bagaimana kita mewujudkannya? Kami berada dalam posisi khusus sejak framework menguji FrameworkController, sebuah controller yang dijalankan di dalam sebuah controller yang dijalankan.

jnm2 pada 14 Jul 2018

Mengesampingkan pengujian kami, arti dari WorkDirectory adalah "direktori yang ditetapkan oleh pengguna untuk menerima semua file keluaran untuk dijalankan." Jadi sebuah tes seharusnya tidak bisa mengubahnya.

Untuk pengujian kami sendiri, kami harus dapat menyetelnya, tetapi setelan tersebut seharusnya tidak memengaruhi pengujian lain jika kami melakukannya dengan benar. Kami mungkin tidak melakukannya dengan benar. 😜

Dalam keadaan darurat, kami dapat membuatnya tidak dapat diubah dan berhenti mengujinya. <ducks>

CharliePoole pada 14 Jul 2018

Itu sebenarnya ide yang keren - lacak apakah bidang statis telah disetel dan lewati pengaturannya setelahnya? Dengan begitu itu tidak dapat diubah dan saya tidak melihat tes apa pun yang memeriksa apakah DefaultTestAssemblyBuilder menyetelnya, jadi kita harus baik-baik saja!

jnm2 pada 14 Jul 2018

Ada tes NUnit yang mengubahnya, dan jika dibuat tidak dapat diubah, mereka mungkin gagal.

oznetmaster pada 14 Jul 2018

@oznetmaster Saya mencari tetapi tidak dapat menemukan tes NUnit yang mengubahnya kecuali secara tidak sengaja. Apakah Anda memiliki berguna?

jnm2 pada 14 Jul 2018

Saya harus mencari arsip saya.

Saya telah memperbaiki masalah dalam pembuatan CF saya dengan melakukan apa yang telah dibahas. Hanya mengizinkan nilai ditetapkan sekali. Saya memeriksa apakah itu nol, dan jika ya, maka izinkan untuk disetel.

                if (options.ContainsKey (FrameworkPackageSettings.WorkDirectory))
                    TestContext.DefaultWorkDirectory = options[FrameworkPackageSettings.WorkDirectory] as string;
                else
                    if (TestContext.DefaultWorkDirectory == null)
                        TestContext.DefaultWorkDirectory = Directory.GetCurrentDirectory ();

oznetmaster pada 14 Jul 2018

Tes yang menjadi masalah adalah tes yang akan memanggil DefaultTestAssemblyBuilder.Build dengan opsi yang tidak menyertakan FrameworkPackageSettings.WorkDirectory, menyebabkan TestContext.DefaultWorkDirectory ditimpa oleh CurrentDirectory. Ini berarti bahwa jika WorkDirectory telah diatur dalam eksekusi tingkat atas, itu akan ditimpa oleh pengujian, dan tidak pernah dipulihkan.

oznetmaster pada 14 Jul 2018

Kedengarannya seperti kita sebaiknya mengambil pendekatan yang sama?

jnm2 pada 14 Jul 2018

Bekerja untuk saya. Build CF saya lulus 100% dari tes NUnit.

oznetmaster pada 14 Jul 2018

👍1

@OmicronPersei Jika Anda ada dalam beberapa hari ke depan, dapatkah Anda mencoba perbaikan ?

jnm2 pada 14 Jul 2018

Ya! Akan mencoba malam ini

OmicronPersei pada 17 Jul 2018

Saya tidak dapat benar-benar mereproduksi bug ini karena nunit3-vs-adapter#528 menyebabkan masalah lain. Ide ide?

OmicronPersei pada 17 Jul 2018

@OmicronPersei Oh. Saya tidak tahu. Apakah menggunakan .runsettings dengan WorkDirectory disetel dengan benar menjadi solusi yang baik?

jnm2 pada 17 Jul 2018

Oke saya sudah mencobanya. TestCaseSourceCanAccessWorkDirectory berhasil tetapi StackTracesAreFiltered gagal dengan jejak pesan/tumpukan yang sama di OP.

OmicronPersei pada 17 Jul 2018

Saya pikir StackTracesAreFiltered harus ditambah menjadi 5. Ini adalah tes bau sehingga kami melihat jika bingkai baru ditambahkan sehingga kami dapat memastikannya tidak lepas kendali.

jnm2 pada 17 Jul 2018

Bagaimana dengan TestCaseSourceCanAccessWorkDirectory , atau apakah itu masih dalam lingkup PR ini?

OmicronPersei pada 18 Jul 2018

ForTestCaseCanAccessWorkDirectory, apakah perbaikan @oznetmaster menyelesaikannya? Jika tidak, kita harus menyelidiki lebih lanjut.

jnm2 pada 18 Jul 2018

Saya tidak dapat mereproduksi masalah pada mesin saya, tes yang dimaksud lolos untuk saya.

OmicronPersei pada 20 Jul 2018

Jangan khawatir, orang lain bisa melakukan bagian itu. Saya suka memiliki PR yang lebih kecil juga.

jnm2 pada 20 Jul 2018

Hanya mencoba melakukan pembersihan rumah; apakah ada alasan mengapa masalah ini harus tetap terbuka atau dapatkah kita menutupnya dengan beberapa jenis resolusi? (Bahkan jika itu adalah WONTFIX).

aolszowka pada 14 Mei 2019

👍1

Tidak, terima kasih telah menunjukkannya. Penutupan.