Autofixture: Membekukan tiruan tidak mengesampingkan instance yang disuntikkan

Dibuat pada 31 Jul 2018 · 1Komentar · Sumber: AutoFixture/AutoFixture

Perilaku Saat Ini

Saat menyuntikkan dua contoh konkret, contoh kedua menimpa yang pertama.

Saat menyuntikkan instance konkret, diikuti oleh instance yang diolok-olok, instance kedua tidak menimpa yang pertama.

Ini membuat gagasan melakukan beberapa tes yang menggunakan tiruan dan beberapa tes yang menggunakan implementasi (menggunakan konstruktor kelas tes untuk berbagi perlengkapan di antara tes) cukup canggung.

Perilaku yang Diharapkan

Saat menyuntikkan dua contoh konkret, contoh kedua menimpa yang pertama.

Saat menyuntikkan instance konkret, diikuti oleh instance yang diolok-olok, instance kedua menimpa yang pertama.

Contoh Perilaku yang Diharapkan

```C#
menggunakan System.Collections.Generic;
menggunakan AutoFixture;
menggunakan AutoFixture.AutoMoq;
menggunakan Moq;
menggunakan Xunit;

namespace SomeNamespace
{
AutoFixtureTests kelas publik
{
[Fakta]
// Lulus
public void Should_OverridePreviouslyInjectedString()
{
const string test1 = "test1";
const string test2 = "test2";

        var fixture = new Fixture();

        fixture.Inject(test1);
        fixture.Inject(test2);

        Assert.Equal(fixture.Create<string>(), test2);
    }

    [Fact]
    // Fails
    public void Should_OverridePreviouslyInjectedInstance()
    {
        var fixture = new Fixture().Customize(new AutoMoqCustomization());

        var sut1 = new List<int>();

        fixture.Inject<IList<int>>(sut1);
        fixture.Freeze<Mock<IList<int>>>();

        var sut2 = fixture.Create<IList<int>>();

        Assert.NotSame(sut1, sut2);
    }
}

}
```

question

Sumber

charles-salmon

Komentar yang paling membantu

Hai @charles-salmon,

Terima kasih telah meluangkan waktu untuk melaporkan ini.

Perilaku yang Anda amati adalah _by design_. Izinkan saya untuk menjelaskan. 🙂

Jika Anda melihat implementasi metode Freeze<T> :

var value = fixture.Create<T>();
fixture.Inject(value);
return value;

Anda akan melihat bahwa yang dilakukannya hanyalah membuat spesimen T dan memasukkannya ke dalam perlengkapan. Memang, metode Freeze muncul sebagai jalan pintas yang praktis untuk operasi ini. Seperti yang ditulis @ploeh dalam postingnya yang memperkenalkan metode Freeze pada tahun 2010:

Ternyata kami menggunakan idiom pengkodean ini begitu banyak sehingga kami memutuskan untuk merangkumnya dalam metode yang mudah. Setelah beberapa perdebatan, kami sampai pada nama Freeze, karena pada dasarnya kami membekukan satu variabel anonim di fixture, melewati algoritme default untuk membuat instance baru.

Mengingat hal itu, tidak mengherankan jika membekukan tipe yang sama T sebagai instance yang disuntikkan menghasilkan instance yang sama.

Sekarang, untuk mengatasi poin Anda:

Ini membuat gagasan melakukan beberapa tes yang menggunakan tiruan dan beberapa tes yang menggunakan implementasi (menggunakan konstruktor kelas tes untuk berbagi perlengkapan di antara tes) cukup canggung.

Mengingat bahwa perlengkapan mewakili _context_ tempat pengujian berjalan, Anda tentu _dapat_ memiliki beberapa pengujian yang berbagi perlengkapan yang sama ; namun, ini harus dibayar dengan mencampuradukkan banyak—dan mungkin bertentangan—kekhawatiran.

Buku Pola xUnit merangkumnya dengan baik :

Masalah terbesar dengan Perlengkapan Bersama adalah bahwa hal itu dapat menyebabkan "tabrakan" antara pengujian yang mungkin mengakibatkan Pengujian Tidak menentu , karena pengujian mungkin bergantung pada hasil pengujian lainnya. Masalah lainnya adalah bahwa perlengkapan yang dirancang untuk melayani banyak tes pasti akan jauh lebih rumit daripada Perlengkapan Minimal yang diperlukan untuk satu pengujian.

Ini "tabrakan" adalah persis apa yang terjadi ketika tes mengharapkan objek tipe T menjadi contoh tertentu, sementara tes lain mengharapkan T menjadi objek palsu .

Karena saya tidak dapat memikirkan skenario pengujian di mana masuk akal untuk tipe yang sama T untuk keduanya menjadi tiruan _dan_ contoh nyata (walaupun saya senang terbukti salah), saya sarankan Anda memiliki ini tes menggunakan perlengkapan yang berbeda, masing-masing dikonfigurasi untuk melayani skenario khusus mereka.

ecampidoglio pada 1 Agu 2018

👍3

>Semua komentar

Hai @charles-salmon,

Terima kasih telah meluangkan waktu untuk melaporkan ini.

Perilaku yang Anda amati adalah _by design_. Izinkan saya untuk menjelaskan. 🙂

Jika Anda melihat implementasi metode Freeze<T> :

var value = fixture.Create<T>();
fixture.Inject(value);
return value;

Ternyata kami menggunakan idiom pengkodean ini begitu banyak sehingga kami memutuskan untuk merangkumnya dalam metode yang mudah. Setelah beberapa perdebatan, kami sampai pada nama Freeze, karena pada dasarnya kami membekukan satu variabel anonim di fixture, melewati algoritme default untuk membuat instance baru.

Mengingat hal itu, tidak mengherankan jika membekukan tipe yang sama T sebagai instance yang disuntikkan menghasilkan instance yang sama.

Sekarang, untuk mengatasi poin Anda:

Ini membuat gagasan melakukan beberapa tes yang menggunakan tiruan dan beberapa tes yang menggunakan implementasi (menggunakan konstruktor kelas tes untuk berbagi perlengkapan di antara tes) cukup canggung.

Buku Pola xUnit merangkumnya dengan baik :

Masalah terbesar dengan Perlengkapan Bersama adalah bahwa hal itu dapat menyebabkan "tabrakan" antara pengujian yang mungkin mengakibatkan Pengujian Tidak menentu , karena pengujian mungkin bergantung pada hasil pengujian lainnya. Masalah lainnya adalah bahwa perlengkapan yang dirancang untuk melayani banyak tes pasti akan jauh lebih rumit daripada Perlengkapan Minimal yang diperlukan untuk satu pengujian.

Ini "tabrakan" adalah persis apa yang terjadi ketika tes mengharapkan objek tipe T menjadi contoh tertentu, sementara tes lain mengharapkan T menjadi objek palsu .

ecampidoglio pada 1 Agu 2018

👍3

Apakah halaman ini membantu?

0 / 5 - 0 peringkat