Autofixture: Masalah integrasi NCrunch dan AutoFixture

Hai, saya pengembang NCrunch.

Saya akan senang untuk bekerja dengan Anda untuk menemukan solusi untuk ini. Dengan desain saat ini, sayangnya saya kehabisan pilihan untuk menyelesaikan masalah hanya di sisi saya dari titik integrasi. Saya percaya bahwa pelari saya kemungkinan bukan satu-satunya yang mengalami masalah dengan desain saat ini.

Seperti yang mungkin Anda pahami melalui berbagai dokumentasi dan posting forum dukungan yang telah saya tulis, akar masalahnya terletak pada pembuatan parameter pengujian acak AutoFixture. Karena parameter pengujian merupakan elemen penting dalam mengidentifikasi pengujian dan kemudian menjalankannya, eksekusi pengujian secara selektif menjadi tidak mungkin jika parameter berubah setiap kali pengujian dibuat/ditemukan.

Satu-satunya cara andal yang dapat saya pikirkan untuk memecahkan masalah ini adalah dengan menghapus semua generasi acak dari parameter pengujian dan sebagai gantinya menggunakan nilai tetap (yaitu placeholder atau consts) sebagai gantinya, atau membatasi penyemaian nilai parameter ke test case itu sendiri. Dengan cara ini, tes akan selalu sama persis dan dapat ditemukan secara konsisten sama seperti tes lainnya. Setiap pengguna yang saya tangani yang telah menggunakan AutoFixture untuk pembuatan parameter telah melakukannya untuk parameter yang mereka tidak 'pedulikan' untuk tujuan pengujian mereka, jadi saya harap pendekatan ini mungkin tidak memiliki kerugian nyata di mata pengguna . Manfaatnya adalah ia juga akan segera bekerja dengan semua versi NCrunch dan tidak memerlukan perubahan kode apa pun ke NCrunch atau runner lainnya.

@remcomulder Terima kasih banyak telah berpartisipasi di sini - sangat dihargai! Saya telah menyelidikinya sedikit dan ingin membagikan temuan saya. Semua temuan saya hanya berlaku untuk xUnit .

TL DR: xUnit mendukung teori semacam itu dan NCrunch juga harus mendukungnya untuk xUnit. Untuk NUnit - itu pertanyaan terbuka dan saya belum menyelidikinya.

Fitur yang kami gunakan tampaknya _legal_ untuk xUnit. Kami memiliki TestDataDiscoverer kami sendiri yang menunjukkan bahwa teori kami tidak dapat ditemukan sebelumnya (karena kami menghasilkan data acak). Kemudian kami menghias AutoDataAttribute kami dengan penemu ini. xUnit menghormati atribut ini dan tidak menyelesaikan nilai parameter selama penemuan.

Saya percaya bahwa pelari saya kemungkinan bukan satu-satunya yang mengalami masalah dengan desain saat ini.

Sebenarnya, itu tidak benar dan R# dan VS bekerja dengan baik dengan teori seperti itu. Mereka juga memungkinkan untuk menjalankan kembali teori tertentu bahkan jika itu berisi data yang dihasilkan secara otomatis. Saya sarankan untuk fokus pada VS karena juga berisi fase penemuan & jalankan dan bersumber terbuka.

Perhatikan kode tes berikut:

using Ploeh.AutoFixture.Xunit2;
using Xunit;

namespace Playground
{
    public class UnitTest
    {
        [Fact]
        public void StableTest()
        {
            Assert.True(true);
        }

        [Theory]
        [InlineData(1)]
        public void StableInlineTest(int value)
        {
            Assert.Equal(1, value);
        }

        [Theory, AutoData]
        public void VolatileTest(int value)
        {
            Assert.True(value % 2 == 0);
        }

        [Theory]
        [InlineAutoData(10)]
        [InlineAutoData(20)]
        [InlineAutoData(30)]
        public void VolatileTestWithInline(int value, int autoValue)
        {
            Assert.NotEqual(value, 40);
        }
    }
}

Proyek perpustakaan uji .NET Framework. VS 2017.3. Kerangka sasaran: 4.5.2. Paket yang diinstal:

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50.6
• AutoFixture.Xunit2 3.50.6

Jika Anda memicu temukan di VS, Anda akan melihat output berikut:

Seperti yang mungkin Anda perhatikan, untuk teori yang mendukung penemuan data ( StableInlineTest ), VS runner menunjukkan data aktual yang akan dijalankan dengan pengujian ( 1 ). Untuk pengujian yang tidak mendukung penemuan data dan berisi data yang dibuat secara otomatis ( VolatileTest , VolatileTestWithInline ) VS tidak menemukan kasus teori dan hanya menunjukkan seluruh teori. Hanya setelah Anda menjalankan, Anda akan dapat melihat nilai untuk pemanggilan khusus ini:

Sekarang Anda dapat menjalankan kembali teori tertentu dan itu akan menjalankan _semua kasus teori_ lagi.

Seperti yang Anda lihat, sebenarnya ada cara untuk mendukung teori tersebut dan xUnit melakukannya dengan sempurna. NCrunch harus memperhitungkan fakta bahwa beberapa kasus teori tidak dapat ditemukan sebelumnya. Untuk teori seperti itu, Anda perlu menjalankan kembali seluruh teori, bukan kasus tertentu. Saya tidak melihat mengapa itu tidak mungkin.

Satu-satunya cara andal yang dapat saya pikirkan untuk menyelesaikan masalah ini adalah dengan menghapus semua parameter pengujian secara acak dan sebagai gantinya menggunakan nilai tetap (yaitu placeholder atau consts) sebagai gantinya

Saat ini xUnit tidak mengekspos API untuk mengubah nama tampilan dan mengganti data yang dihasilkan dengan placeholder. Saya telah membuat masalah untuk mereka (lihat di sini ), namun jawaban Brad adalah bahwa itu tidak nyata dan mereka menyarankan untuk menonaktifkan penemuan, yang sudah kami lakukan.

atau sebaliknya membatasi penyemaian nilai parameter ke kasus uji itu sendiri.

Sayangnya, saat ini tidak mungkin untuk produk kami dan banyak hal harus ditulis ulang untuk mendukung benih hangus.

data anggota

Dalam dokumentasi di sini Anda memiliki sampel lain (saya telah menulis ulang ke XUnit):

public class MemberDataSample
{
    public IEnumerable<object[]> GetData()
    {
        yield return new object[]
        {
            DateTime.Now
        };
    }

    [Theory, MemberData(nameof(GetData), DisableDiscoveryEnumeration = true)]
    public void DateTheory(DateTime dt)
    {
        Assert.True(DateTime.Now - dt < TimeSpan.FromMinutes(1));
    }
}

Ini benar-benar legal untuk xUnit karena ada atribut DisableDiscoveryEnumeration . Ini bekerja seperti contoh di atas - kasus teori tidak ditemukan sebelumnya.

Garis bawah

Tampaknya xUnit menyediakan instrumen untuk memahami apakah pengujian bersifat fluktuatif atau tidak (melalui dukungan enumerasi pra-penemuan). Anda dapat menggunakan implementasi VS sebagai contoh untuk memahami bagaimana mereka menanganinya dan melakukan hal yang sama pada produk Anda. Kemungkinan, mereka hanya menggunakan xUnit SDK dan pesan mereka tenggelam.

Mengingat bahwa R# dan VS mendukung teori yang bagus, itu membuat saya berpikir bahwa sebenarnya semuanya benar dengan produk kami..

Adapun NUnit - mari kita bahas setelah itu karena saya belum menyelidikinya. Mungkin, kami tidak memiliki API untuk itu.

Bisakah Anda membagikan pendapat Anda tentang dukungan xUnit mengingat temuan saya? Maukah Anda menambahkan dukungan untuk
xUnit (berhenti menjalankan kembali semua tes) dan berhenti untuk menunjukkan peringatan ketidakcocokan itu? 😉

Sepertinya aku mungkin berhutang maaf padamu di sini. Kasus penggunaan yang Anda jelaskan di atas berfungsi dengan benar di bawah NCrunch, karena alasan yang telah Anda jelaskan. Xunit menghindari pra-pencacahan teori dan meruntuhkannya menjadi satu tes di mana ia diidentifikasi dan dieksekusi dengan aman. Saat menguji ini sekarang, saya dapat mengonfirmasi bahwa NCrunch melakukan ini dengan benar. Sepertinya kami tidak memiliki masalah yang jelas dengan InlineAutoData.

Saya tidak yakin mengapa ini gagal untuk saya sebelumnya. Saat ini saya tidak dapat membuat skenario sendiri yang gagal. Saya tahu saya memiliki pengguna yang menyebutkan kepada saya bahwa InlineAutoData tidak berfungsi, meskipun saya kira mereka harus maju dan memberikan contoh di mana hal ini terjadi.

Saya ingin menarik perhatian Anda ke kasus penggunaan tertentu yang saya tahu akan merusak NCrunch dan VS Runner. Saya berasumsi itu juga akan merusak ReSharper dan TD.NET, meskipun saya belum menguji ini karena saya belum menginstalnya:

using Ploeh.AutoFixture;
using Ploeh.AutoFixture.Xunit2;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;

namespace XUnitAutoFixture
{
    public class TestFixture
    {
        private static readonly Fixture Fixture = new Fixture();

        public static IEnumerable<object[]> SomeTestData()
        {
            yield return new object[] { Fixture.Create<string>() };
            yield return new object[] { Fixture.Create<string>() };
        }

        [Theory, MemberData(nameof(SomeTestData))]
        public void Test(object value)
        {

        }
    }
}

Kode di atas akan gagal di bawah semua skenario eksekusi selektif. Namun, itu akan lulus jika tes ditemukan dan dieksekusi pada langkah yang sama. Skenario ini adalah katalis di balik peringatan yang diberikan oleh NCrunch tentang AutoFixture, karena pengguna melakukan ini dan meminta dukungan. Mengingat bahwa saya tidak tahu tentang penonaktifan AutoFixture pra-pencacahan, saya berasumsi (salah) bahwa InlineAutoData adalah sama.

Asumsi saya saat ini adalah Anda tidak mendukung skenario seperti itu. Apakah ini benar?

Saat menguji ini sekarang, saya dapat mengonfirmasi bahwa NCrunch melakukan ini dengan benar.

Itu hebat! Senang mendengar bahwa sebenarnya xUnit didukung penuh oleh NCrunch Adapun NUnit - selalu canggung dan kami perlu menyelidiki apa yang dapat kami lakukan di sana.

Namun, saya masih mengamati masalah dengan NCrunch dan AutoFixture. Saat ini saya memiliki proyek xUnit dengan AutoFixture dan jika saya mengubah bahkan satu baris, semua tes dijalankan kembali. Tampaknya Anda mengaktifkan perilaku tersebut saat mendeteksi AutoFixture untuk memastikan tidak ada yang terlewat.

Apakah begitu? Jika ya, bisakah Anda memperbaikinya untuk menonaktifkan perilaku seperti itu untuk xUnit karena semuanya baik-baik saja di sana?

Saya ingin menarik perhatian Anda ke kasus penggunaan tertentu yang saya tahu akan merusak NCrunch dan VS Runner.
Asumsi saya saat ini adalah Anda tidak mendukung skenario seperti itu. Apakah ini benar?

Ya, skenario itu akan menghancurkan semua pelari. Namun, seperti yang ditunjukkan dengan benar di suatu tempat di forum Anda, itu bukan karena AutoFixture, karena Anda mungkin menulis sesuatu seperti ini yang juga tidak akan berfungsi:

public class TestFixture
{
    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { DateTime.Now.Ticks };
        yield return new object[] { DateTime.Now.Ticks };
    }

    [Theory, MemberData(nameof(SomeTestData))]
    public void Test(object value)
    {

    }
}

Untuk skenario seperti itu, Anda bertanggung jawab untuk menonaktifkan pra-penemuan secara manual, sehingga akan terlihat seperti ini (perhatikan properti DisableDiscoveryEnumeration ):

public class TestFixture
{
    private static readonly Fixture Fixture = new Fixture();

    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { Fixture.Create<string>() };
        yield return new object[] { Fixture.Create<string>() };
    }

    [Theory, MemberData(nameof(SomeTestData), DisableDiscoveryEnumeration = true)]
    public void Test(object value)
    {

    }
}

Sebenarnya, ini adalah skenario yang sangat jarang karena kita memiliki atribut AutoData dan InlineAutoData untuk pembuatan data. Juga AutoFixture hanyalah sebuah alat dan itu tanggung jawab pengembang untuk menggunakannya dengan benar.

Saya tidak akan memindahkan NCrunch ke mode khusus hanya karena ada orang yang salah menggunakan alat. Hal terbaik yang dapat kami lakukan di sini adalah meletakkan Masalah yang Diketahui di suatu tempat untuk menggambarkan skenario khusus ini dan meminta orang untuk menggunakan xUnit dengan benar (karena mereka mungkin tidak mengetahuinya).

Bisakah Anda mengonfirmasi bahwa Anda menjalankan tes dengan cara khusus jika Anda mendeteksi AutoFixture dan jika demikian, bisakah Anda menonaktifkan mode itu untuk xUnit (untuk NUnit lebih baik tetap seperti itu). Juga kemungkinan halaman ini juga harus diperbarui.

Saat ini, NCrunch tidak menerapkan penanganan khusus untuk AutoFixture di luar peringatan kompatibilitas. Perilaku yang Anda alami mungkin disebabkan oleh mode mesin yang Anda pilih. Ini sepenuhnya dapat dikonfigurasi - jika Anda beralih ke mode 'Jalankan pengujian yang terpengaruh secara otomatis, yang lain secara manual', saya pikir Anda akan melihat mesin berperilaku seperti yang Anda harapkan.

Dengan apa yang saya pelajari dari Anda, saya merasa siap untuk menghapus peringatan AutoFixture dari NCrunch sepenuhnya. Saya sudah diyakinkan oleh pengguna untuk menulis ulang, karena menjadi jelas sejak awal bahwa peringatan itu terlalu luas dan beberapa fitur AutoFixture masih berfungsi dengan benar. Saya pikir saya telah salah paham dengan serius bagaimana AutoFixture diimplementasikan di bawah xunit.

Jadi saya kira ini mungkin skenario kasus terbaik bagi kami. Kasus penggunaan yang paling merusak saya tidak didukung secara teknis, dan yang lainnya berfungsi dengan baik. Sementara itu, saya akan dengan senang hati mencoba melupakan rasa malu saya sendiri karena telah menguji dan memverifikasi ini ke kesimpulan yang salah, jika Anda dapat menemukan alasan untuk memaafkan saya atas peringatan kompatibilitas yang terlalu bersemangat.

Sementara itu, saya akan dengan senang hati mencoba melupakan rasa malu saya sendiri karena telah menguji dan memverifikasi ini ke kesimpulan yang salah, jika Anda dapat menemukan alasan untuk memaafkan saya atas peringatan kompatibilitas yang terlalu bersemangat.

Jangan khawatir! Tidak apa-apa dan kita semua di sini untuk saling membantu memahami berbagai hal Bagus sekali Anda menindaklanjuti tiketnya dan kami mendiskusikannya - itu terlalu banyak

Dengan apa yang saya pelajari dari Anda, saya merasa siap untuk menghapus peringatan AutoFixture dari NCrunch sepenuhnya.

Yah, kami masih memiliki masalah dengan NUnit (kami sedang dalam perjalanan ), jadi pesan ini tampaknya relevan untuk proyek NUnit. Mungkin, masuk akal untuk menonaktifkannya hanya untuk xUnit, kecuali kami memperkenalkan dukungan penuh untuk NUnit (atau setidaknya cara untuk mengaktifkan dukungan itu).

Saya masih memiliki satu hal yang tidak jelas bagi saya. Apa artinya Anda tidak mendukung misalnya AutoFixture & NUnit? Ya, nama pengujian berbeda untuk setiap waktu, namun apakah penting jika Anda menjalankan kembali semua pengujian (jika mode mesin diatur demikian)? Atau apakah itu berarti Anda tidak lebih mendukung mesin "Hanya yang terkena dampak" untuk mereka? Pikiran saya adalah bahwa alih-alih mengatakan No support , mungkin lebih baik untuk mempersempit ke beberapa skenario tertentu yang tidak kami dukung, sementara yang lain seharusnya baik-baik saja.

'Jalankan pengujian yang terpengaruh secara otomatis, yang lain secara manual'

Saya tidak dapat menemukan pengaturan ini pada instalasi 3.10.0.20 . Apakah maksud Anda pengaturan Only consider tests 'Out of date' if they are 'Impacted' yang harus disetel ke true ? Maaf jika saya melewatkannya di suatu tempat - saya agak baru dalam produk ini..

Pembaruan dokumentasi

Mungkin masuk akal untuk tidak _menghapus_ case dengan xUnit dan AutoFixture dari halaman ini , tetapi menjelaskan cara menggunakannya dengan benar (gunakan atribut DisableDiscoveryEnumeration ). Juga akan keren untuk menggambarkan sampel "Kasus Uji NUnit Dengan Nama Tidak Konsisten" untuk xUnit dan meminta untuk menggunakan atribut DisableDiscoveryEnumeration bersama dengan MemberDataAttribute .

Saya masih memiliki satu hal yang tidak jelas bagi saya. Apa artinya Anda tidak mendukung misalnya AutoFixture & NUnit? Ya, nama pengujian berbeda untuk setiap waktu, namun apakah penting jika Anda menjalankan kembali semua pengujian (jika mode mesin diatur demikian)? Atau apakah itu berarti Anda tidak lebih mendukung mesin "Hanya yang terkena dampak" untuk mereka? Pikiran saya adalah bahwa alih-alih mengatakan Tidak ada dukungan, mungkin lebih baik untuk mempersempit beberapa skenario tertentu yang tidak kami dukung, sementara yang lain seharusnya baik-baik saja.

Ini karena umur pengujian di bawah NCrunch. NCrunch memiliki status penting yang ditetapkan untuk setiap tes (pikirkan hasil lulus/gagal, data cakupan kode, data kinerja, keluaran jejak, dll). Data ini bertahan selama pengujian terus 'ditemukan' oleh kerangka pengujian, bahkan di antara sesi VS. Ketika kerangka pengujian melaporkan tidak ada pengujian dengan pengenal yang sama, pengujian dianggap hilang dan semua status dihancurkan.

Saat pengujian dibuat menggunakan parameter yang tidak stabil, setiap panggilan ke kerangka pengujian untuk menemukan hasil pengujian dalam pengujian baru yang dibuat, karena pengidentifikasi pengujian telah berubah. Hasilnya adalah bahwa setiap kali NCrunch memanggil NUnit untuk menemukan pengujian (secara konsisten setelah setiap pembuatan proyek pengujian), semua status yang ditahan untuk pengujian dengan parameter yang tidak stabil akan dibuang. Jadi itu buruk. Ini berarti bahwa deteksi benturan tidak akan berfungsi, dan mesin melakukan banyak pekerjaan ekstra untuk menjalankan kembali tes dan membolak-balik hasil sementara.

Masalahnya berjalan lebih dalam sekalipun. Jika dumping status pengujian adalah satu-satunya masalah nyata, penanganan untuk pengujian yang tidak stabil masih dapat 'berfungsi' dalam arti bahwa pengujian tersebut akan tetap dijalankan oleh mesin dan hasilnya akan dilaporkan. Masalah yang lebih dalam datang dari paralelisasi NCrunch, eksekusi selektif dan pemrosesan terdistribusi.

Untuk melakukan eksekusi paralel, NCrunch perlu menggunakan beberapa proses pengujian yang menjalankan tes secara paralel. Mekanisme NUnit sedemikian rupa sehingga tes harus ditemukan sebelum dapat dieksekusi. Ini berarti bahwa harus ada langkah penemuan terpisah yang dieksekusi di dalam setiap proses yang digunakan untuk eksekusi, jadi jika kita memiliki dua proses, maka kita perlu menemukan tes dua kali. Jika pengujian memiliki parameter yang tidak stabil, setiap proses akan memiliki rangkaian pengujian yang sama sekali berbeda, sehingga tidak mungkin bagi mesin untuk membagi daftar master pengujian yang lengkap antara proses yang akan dieksekusi. Masalah ini juga meluas saat menggunakan pemrosesan terdistribusi, karena proses eksekusi jarak jauh berjalan pada perangkat keras yang berbeda di lingkungan yang sama sekali berbeda.

Ada juga masalah eksekusi selektif. Mode operasi default NCrunch adalah selalu membuat proses pengujian baru ketika secara khusus diperintahkan untuk menjalankan pengujian. Ini untuk membersihkan batu tulis dan sekonsisten mungkin dengan pelari lain. Fitur seperti itu tidak dapat bekerja dengan parameter yang tidak stabil, karena memunculkan proses pengujian baru memerlukan pengujian penemuan kembali, yang selanjutnya tidak dapat diidentifikasi jika parameternya telah berubah.

NUnit memang memiliki sistem ID internalnya sendiri yang dapat digunakan untuk mengidentifikasi pengujian dengan parameter yang tidak stabil di antara proses, tetapi sistem ID ini didasarkan pada urutan pembuatan pengujian (yaitu inkremental). Sistem seperti itu tidak dapat digunakan oleh runner pengujian mana pun yang perlu mengelola status pengujian di beberapa versi rakitan pengujian, karena jika pengguna membuat pengujian baru, semua ID akan tidak berurutan dan data akan menjadi sangat menyesatkan. . Pengembang NUnit telah menyatakan minatnya untuk menjauh dari sistem berbasis urutan ini dan menuju ID yang dihasilkan dari atribut pengujian itu sendiri, yang akan mirip dengan bagaimana Xunit melakukannya (dan kemungkinan tidak akan bekerja dengan parameter yang tidak stabil).

Saya masih percaya bahwa cara terbaik untuk menyelesaikan masalah ini adalah dengan melakukan penyemaian parameter yang tidak stabil secara konsisten. Selalu ada konsep bahwa pengujian harus dapat diulang dan konsisten, yang sulit dicapai jika pengujian sepenuhnya mengacak semua inputnya. Dalam praktik sebenarnya, tes yang menghasilkan data unggulan secara acak untuk eksekusinya adalah tes yang sama sekali baru setiap kali dibuat, karena kode dapat berperilaku berbeda berdasarkan data yang dimasukkan.

Saya tidak dapat menemukan pengaturan ini pada instalasi 3.10.0.20 saya. Apakah maksud Anda Hanya pertimbangkan tes 'Kedaluwarsa' jika itu adalah pengaturan 'Berdampak' yang harus disetel ke true? Maaf jika saya melewatkannya di suatu tempat - saya agak baru dalam produk ini..

Buka menu NCrunch, pilih 'Set engine mode', dan Anda akan melihat opsi di sana. Jika tidak ada, mungkin Anda menggunakan solusi yang dijalankan oleh versi NCrunch yang jauh lebih lama dan hanya menampilkan mode mesin lawas. Hanya membuat solusi baru di suatu tempat harus menyelesaikan ini.

@remcomulder Wow! Terima kasih atas penjelasan yang begitu detail! Sekarang saya melihat bahwa memang lebih mudah untuk mengatakan bahwa AutoFixture & NUnit saat ini tidak didukung karena ada beberapa masalah BESAR di bawah tenda

Saya masih percaya bahwa cara terbaik untuk menyelesaikan masalah ini adalah dengan melakukan penyemaian parameter yang tidak stabil secara konsisten.

Sebenarnya, dalam PR ini kami memiliki ide yang sedikit berbeda. Kami ingin mengubah nama tes agar stabil. Misalnya, diberikan tes seperti ini:

    [Test, StableNameAutoData]
    public void Sample(int a, Data d1, DataWithToString d2, ISomeData d3)
    {
        Assert.IsTrue(true);
    }

nama tesnya adalah:

NUnit3RunnerTest709.TestNameTester.Sample(auto<System.Int32>,auto<NUnit3RunnerTest709.Data>,auto<NUnit3RunnerTest709.DataWithToString>,auto<Castle.Proxies.ISomeDataProxy>)

Nama akan selalu sama selama setiap penemuan/eksekusi, sedangkan nilai argumen yang sebenarnya akan berbeda untuk setiap waktu.

Mengingat pengetahuan mendalam Anda tentang NUnit, bagaimana Anda mengevaluasi pendekatan ini? Apakah itu akan berhasil untuk Anda? Saya berharap Anda menggunakan nama teori, daripada mengikat nilai argumen tertentu. Oleh karena itu, jika nama tes stabil, Anda seharusnya tidak mengalami masalah karena dapat diidentifikasi sekarang. Bisakah Anda mengonfirmasi sebelum kami mulai menerapkan ini? ️

Selalu ada konsep bahwa pengujian harus dapat diulang dan konsisten, yang sulit dicapai jika pengujian sepenuhnya mengacak semua inputnya.

Mungkin, suatu hari kami akan mendukung benih stabil sehingga tes dapat diputar ulang dengan argumen yang sama, namun saat ini kami cukup jauh dari itu, jadi itu tidak realistis Sebaliknya, kami berharap pernyataan pengguna akan cukup tepat untuk dipahami nanti mengapa tes gagal bahkan jika input diacak dalam beberapa rentang.

Mengingat pengetahuan mendalam Anda tentang NUnit, bagaimana Anda mengevaluasi pendekatan ini? Apakah itu akan berhasil untuk Anda? Saya berharap Anda menggunakan nama teori, daripada mengikat nilai argumen tertentu. Oleh karena itu, jika nama tes stabil, Anda seharusnya tidak mengalami masalah karena dapat diidentifikasi sekarang. Bisakah Anda mengonfirmasi sebelum kami mulai menerapkan ini? ️

Sayangnya pengetahuan saya tentang NUnit jauh dari dalam :( NCrunch pada dasarnya hanya mengambil nama NUnit kembali ke sana, dan menggunakan ini untuk menghasilkan pengenal. Jadi secara teori, selama solusi Anda memang mengubah/menstabilkan nama fisik tes sebagai dikembalikan oleh NUnit API, maka kita seharusnya baik-baik saja di sini
untuk NCrunch setidaknya.

Sesuatu yang harus diwaspadai adalah potensi pengguna untuk membuat beberapa tes dengan tanda tangan yang sama. Jika parameter dalam nama dilucuti menjadi tipe mentah, ini menjadi jauh lebih mungkin/mungkin. Selama Anda menyadari skenario ini, Anda mungkin bisa membuat kode dalam kesalahan atau sesuatu untuk mencegahnya.

@remcomulder Hanya untuk memperbarui Anda, sehingga kami akhirnya dapat menutup masalah ini.

Seperti yang telah dibahas di atas, kerangka kerja xUnit didukung secara native. Namun, untuk NUnit masalahnya tidak jelas karena tidak mendukung tes dengan nama yang mudah menguap.

Kami baru-baru ini menggabungkan PR dan merilis versi baru AutoFixture ( v3.51.0 ) yang menambahkan dukungan untuk nama stabil untuk NUnit. Untuk saat ini, tindakan manual diperlukan dari sisi pengguna (lihat di sini ), namun di v4 saya akan membuatnya out-of-the-box.

Saya baru saja menguji dan menemukan bahwa jika saya menggunakan pendekatan di atas, NCrunch hanya dapat menjalankan tes yang dimodifikasi dan tampaknya sekarang berfungsi dengan benar. Saya tidak yakin apakah beberapa tindakan dari pihak Anda diperlukan (misalnya mendokumentasikannya di suatu tempat). Juga akan baik-baik saja jika Anda menguji fitur baru itu dan memberi tahu kami apakah itu berfungsi dengan baik sekarang, jadi kami dapat beristirahat

@zvirja Terima kasih telah mengulang saya dalam hal ini. Saya telah memberikan pekerjaan ini tes cepat, dan itu terlihat solid bagi saya. Dengan menghapus elemen acak dari nama tes, pelari dapat secara konsisten mengidentifikasi tes di seluruh sesi dan semuanya tampak baik-baik saja :)

Saya punya ide meskipun saya pikir mungkin menghemat waktu kami dalam dukungan pengguna. Satu masalah yang kita semua temukan dengan perangkat lunak adalah banyak orang tidak membaca dokumen sebelum mereka mengambil alat. Sangat berguna mengetahui bahwa kami sekarang dapat memberi tahu mereka tentang cara menyelesaikan masalah nama unik di bawah NUnit, tetapi pendekatan terbaik selalu membuat masalah selesai dengan sendirinya.

Saya perhatikan bahwa secara default, AutoFixture akan menggunakan VolatileNameTestMethodBuilder. Saya menerima ini karena alasan kompatibilitas ke belakang dan saya setuju bahwa ini masuk akal. Tetapi bagaimana jika kita membiarkan default ini ditimpa menggunakan variabel lingkungan? Jika kita dapat menentukan variabel lingkungan (misalnya, 'AutoFixture.FixedTestNames'=='1') untuk memaksa AutoFixture menggunakan VolatileNameTestMethodBuilder, pelari dapat menentukan pembuatnya terlebih dahulu, tanpa pengguna perlu melakukan apa pun. Ini juga akan menjadi bonus bagi orang-orang yang menggunakan banyak pelari, karena mereka secara implisit dapat menggunakan pembangun yang berbeda untuk setiap pelari (tanpa perlu usaha apa pun) dan mendapatkan yang terbaik dari kedua dunia.

Bagaimana menurutmu?

Saya telah memberikan pekerjaan ini tes cepat, dan itu terlihat solid bagi saya.

Itu luar biasa! Artinya kami dapat menutup masalah ini karena sekarang semuanya berfungsi dengan baik. Terima kasih atas pengujian dan partisipasi Anda di sini

Bagaimana menurutmu?

Saya rasa saya mendapatkan solusi yang jauh lebih baik dan sederhana - kami akan menjadikan FixedNameTestMethodBuilder sebagai strategi default di v4 (rilis utama kami berikutnya) yang akan dirilis dalam satu atau dua bulan mendatang. PR yang sesuai telah disetujui , jadi kode akan ada di sana. Oleh karena itu, kami akan bekerja dengan baik di luar kotak dan jika seseorang membutuhkan nama pengujian yang mudah berubah - dia akan ikut serta secara manual, dengan jelas memahami konsekuensinya.

Nanti kita bisa melakukan sesuatu seperti yang Anda sarankan - tambahkan strategi peralihan yang memeriksa variabel lingkungan/AppConfig, namun saya lebih suka melakukannya hanya jika itu memang diperlukan.

Saya pikir saya berakhir dengan solusi yang jauh lebih baik dan lebih sederhana - kami akan menjadikan FixedNameTestMethodBuilder sebagai strategi default di v4 (rilis utama kami berikutnya) yang akan dirilis dalam satu atau dua bulan mendatang.

Itu akan bekerja dengan baik untuk saya :) Saya senang! Terima kasih untuk semua usaha Anda.

Keren Sekali lagi terima kasih atas balasan dan kerjasamanya 👍

Saya menutup yang ini karena tidak ada tindakan yang diperlukan lebih dari kedua belah pihak.

@remcomulder @zvirja Hanya ingin mengatakan bahwa diskusi ini (yang membantu saya memahami masalah serupa), dan dedikasi yang Anda tunjukkan di sini, tidak lain adalah luar biasa! Terima kasih keduanya untuk produk hebat Anda.