Autofixture: 複雑な制約を持つオブジェクトを生成する

無線封止でごめんなさい。 私たちは生きています、そして私はすぐに返事をします-最近私の主要な仕事で非常に忙しいです。 NSubstitute v4リリースにも取り組んでいるため、時間は非常に限られています。リソース：物思いにふける：質問は難しいので、回答を投稿する前に、考えられるすべての方法について考えてください。

忍耐をありがとう、お楽しみに：ウィンク：

やあ、
そのニュースはありますか？
プレッシャーはありません（私はドリルを知っています😄、そしてそれは実際にはブロックされていません、私はいくつかの知識に基づいたアドバイスが本当に欲しいです）、それはあなたがある程度の可視性を持っているかどうかを知ることだけです。
どうもありがとう！

良い一日！ 最後に、私は答えるために少しタイプを割り当てました-非常に遅れた返信をお詫びします😊

まず、AutoFixtureのコアは非常に単純であり、制約のある複雑なツリーのサポートが組み込まれていないことに注意してください。 要するに、作成戦略は次のようなものです。

• パブリックコンストラクターまたは静的ファクトリメソッド（現在のタイプのインスタンスを返す静的メソッド）を探します。
• コンストラクター引数を解決し、インスタンスをアクティブ化します。
• 書き込み可能なパブリックプロパティとフィールドに生成された値を入力します。

現在のアプローチでは、以前に発見したように、どういうわけか依存関係の制約を制御することはできません。

特定のタイプを構築する方法を指定するためのカスタマイズポイントがいくつかありますが、それらは比較的単純であり、それらの複雑なルールをサポートしていません。

AutoFixtureでこの種の構造のインスタンスを生成するための最良のアプローチは何でしょうか？ つまり、私は明らかにカスタマイズを作成しますが、そこに何を入れますか？

• ランダムなintを生成し、そのうちの1つが素数になるまでループしますか（またはもちろん素数生成アルゴリズムを実行しますか）？ これはこの種の制約には受け入れられる可能性がありますが、制約を遵守するのがより難しい場合、それはすぐにコストがかかることになります。

• いくつかの許容可能な値の有限リストを提供しますか？

残念ながら、ここには特効薬はありません。アプローチは状況によって異なります。 値がランダムすぎることに依存しない場合、または単一のSUTが1〜2の素数しか消費しない場合は、素数をハードコーディングしてそれらから選択するのが適切な場合があります（ ElementsBulider<>組み込みヘルパーがあります）そのような場合）。 一方、素数の大規模なリストが必要で、長い素数シーケンスを操作する場合は、それらを動的に生成するアルゴリズムをコーディングすることをお勧めします。

さらに、理論的には個別にランダムにすることができるいくつかの引数を取るもののインスタンスを作成しようとしているとしましょうが、それはそれらの間でいくつかの検証を行います（たとえば、argAはargBの場合にのみこの値の範囲に入ることができますはtrueであり、argCはargA値に応じて異なる検証ルールに準拠する必要があります。そうでない場合、argC.XプロパティはargA.Xプロパティと一致する必要があります。

この場合、あなたはどうしますか？

本当に良い質問ですが、残念ながらAutoFixtureでは箱から出してすぐにそれをうまく解決することはできません。 通常、私はタイプごとにカスタマイズを分離しようとしているので、1つのタイプのカスタマイズは、単一のタイプの作成のみを制御します。 しかし、私の場合、タイプは独立しており、明らかにあなたのケースではうまく機能しません。 また、AutoFixtureはすぐに使用できるコンテキストを提供しないため、特定のタイプのカスタマイズを作成する場合、でオブジェクト（内部的には標本と呼ばれる）を作成しているコンテキストを明確に理解することはできません。

私の頭の上に、私は通常、次の戦略をお勧めすると思います：

• 単一のオブジェクトタイプのみの作成を制御する方法で、タイプごとにカスタマイズを作成してみてください。
• 特定の制約を使用して依存関係を作成する必要がある場合は、カスタマイズでもそれらの依存関係を有効化することをお勧めします。 依存関係が変更可能である場合は、AutoFixtureに依存関係を作成してもらい、後で互換性があるように構成することができます。

このようにして、内部アーキテクチャとあまり矛盾しないようにし、それがどのように機能するかが明確になります。 もちろん、この方法は非常に冗長になる可能性があります。

複雑な制約のあるケースがそれほど一般的でない場合は、既存の機能で十分な場合があります。 しかし、ドメインモデルがそのようなケースで本当にいっぱいである場合、率直に言ってAutoFixtureはあなたにとって最良のツールではないかもしれません。 おそらく、このような問題を最もエレガントな方法で解決できる、より優れたツールが市場に出回っています。 もちろん、AutoFixtureは非常に柔軟性があり、ほとんどすべてをオーバーライドできるため、AutoFixtureコアの上にいつでも独自のDSLを作成できます...ただし、どちらの方法が安価かを評価する必要があります😉

@ploehにも彼の考えを聞いてみましょう。 通常、マークの答えは深く、結果を解決するのではなく、最初に根本的な原因を見つけようとします😅

他にご不明な点がございましたら、お問い合わせください。 いつでもお答えいたします。

PS FWIW、私はあなたにサンプルを提供することに決めました、そこで私はAutoFixtureで遊んで、同様の問題を解決しようとしました（私はそれを単純に保とうとしました、そしてあなたの場合それは完全に機能しないかもしれません）：

`` `c＃
システムを使用する;
AutoFixtureを使用します。
AutoFixture.Xunit2を使用します。
Xunitを使用する;

名前空間AutoFixturePlayground
{{
パブリック静的クラスUtil
{{
public static bool IsPrime（int number）
{{
//からコピーhttps://stackoverflow.com/a/15743238/2009373

        if (number <= 1) return false;
        if (number == 2) return true;
        if (number % 2 == 0) return false;

        var boundary = (int) Math.Floor(Math.Sqrt(number));

        for (int i = 3; i <= boundary; i += 2)
        {
            if (number % i == 0) return false;
        }

        return true;
    }
}

public class DepA
{
    public int Value { get; set; }
}

public class DepB
{
    public int PrimeNumber { get; }
    public int AnyOtherValue { get; }

    public DepB(int primeNumber, int anyOtherValue)
    {
        if (!Util.IsPrime(primeNumber))
            throw new ArgumentOutOfRangeException(nameof(primeNumber), primeNumber, "Number is not prime.");

        PrimeNumber = primeNumber;
        AnyOtherValue = anyOtherValue;
    }
}

public class DepC
{
    public DepA DepA { get; }
    public DepB DepB { get; }

    public DepC(DepA depA, DepB depB)
    {
        if (depB.PrimeNumber < depA.Value)
            throw new ArgumentException("Second should be larger than first.");

        DepA = depA;
        DepB = depB;
    }

    public int GetPrimeNumber() => DepB.PrimeNumber;
}

public class Issue1067
{
    [Theory, CustomAutoData]
    public void ShouldReturnPrimeNumberFromDepB(DepC sut)
    {
        var result = sut.GetPrimeNumber();

        Assert.Equal(sut.DepB.PrimeNumber, result);
    }
}

public class CustomAutoData : AutoDataAttribute
{
    public CustomAutoData() : base(() =>
    {
        var fixture = new Fixture();

        // Add prime numbers generator, returning numbers from the predefined list
        fixture.Customizations.Add(new ElementsBuilder<PrimeNumber>(2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41));

        // Customize DepB to pass prime numbers only to ctor
        fixture.Customize<DepB>(c => c.FromFactory((PrimeNumber pn, int anyNumber) => new DepB(pn, anyNumber)));

        // Customize DepC, so that depA.Value is always less than depB.PrimeNumber
        fixture.Customize<DepC>(c => c.FromFactory((DepA depA, DepB depB, byte diff) =>
        {
            depA.Value = depB.PrimeNumber - diff;
            return new DepC(depA, depB);
        }));

        return fixture;
    })
    {
    }
}

/// <summary>
/// A helper type to represent a prime number, so that you can resolve prime numbers 
/// </summary>
public readonly struct PrimeNumber
{
    public int Value { get; }

    public PrimeNumber(int value)
    {
        Value = value;
    }

    public static implicit operator int(PrimeNumber prime) => prime.Value;
    public static implicit operator PrimeNumber(int value) => new PrimeNumber(value);
}

}
`` `

こんにちは@zvirja

うわー、詳細な答えをありがとう、それは本当に面白いです。 私はいくつかのテストを行い、それが何をする価値があるかを見積もる必要がありますが、全体としてこれは素晴らしいことです。

処理する依存関係がそれほど多くないと思うので、あなたのアプローチが良い方法かもしれません。 もちろん、 @ ploehに追加するものがあれば、光栄に思います👌

もう一度ありがとう、良い仕事を続けてください！

AutoFixtureとプロパティベースのテストの両方での私の経験では、次のような問題に対処するには、基本的に2つの方法があります。

• フィルタリング
• アルゴリズムによる作成

（私が書いているように、私の直感は、これらがそれぞれ_catamorphisms_と_anamorphisms_である可能性があることを示唆していますが、これについてもう少し考える必要があるので、これはさておき、ほとんど私自身へのメモです。）

ランダムに生成された値のほとんどが、適合しなければならない制約に適合する場合は、既存のジェネレーターを使用しますが、時折不適切な値を破棄することが、問題に対処する最も簡単な方法である可能性があります。

一方、フィルターがほとんどのランダムデータを破棄することを意味する場合は、代わりに、おそらくランダムシード値に基づいて、問題の制約に適合する値を生成するアルゴリズムを考え出す必要があります。

数年前、私はFsCheckのコンテキストで両方のアプローチのいくつかの簡単な例を示す講演をしました。 このプレゼンテーションは、実際には同じアプローチを採用したトークの進化形ですが、代わりにAutoFixtureを使用しています。 残念ながら、その話の録音はありません。

両方の方法で素数の要件に対処できます。

フィルタのアプローチは、制約のない数を生成し、実際に素数になるまで数を破棄することです。

アルゴリズムのアプローチは、素数を生成するために素数ふるいのようなアルゴリズムを使用することです。 ただし、これはランダムではないため、ランダム化する方法を理解することをお勧めします。

AutoFixtureで制約された値を処理する方法に関する全体的な質問は、他の人がライブラリを見始めるとすぐに出てきました。当時、私はまだ参照している記事を書きました： http ：

相互に関連する複数の値の質問に関して、私は一般的なガイダンスを与えたくありません。 この種の質問は、多くの場合XY問題です。 多くの場合、詳細を理解すれば、代替設計によってAutoFixtureだけでなく、製品コードベース自体の問題も解決できる可能性があります。

XY問題が存在する場合でも、これが正当な懸念事項となる可能性がある状況はまだありますが、私の経験では、それらはケースバイケースで対処したいと思います。レア。

ですから、具体的な例があればお役に立てればと思いますが、一般的な質問に有意義に答えられるとは思いません。

@ploehこの回答に感謝します。これは、私が検討していたアプローチを裏付けるものです（そして、カタモルフィズムとアナモルフィズムに興味を持ってくれました😃）。
私は相互依存値がほとんどXY問題であることに完全に同意します（少なくとも私の場合）、問題は、レガシー（テストされていない😢）コードで作業するとき、それらの値を扱うことは、私たちが得るまで、とにかくいくつかのテストを書くための良いスタートだったということですこれを適切にリファクタリングする時間。

とにかく、あなたの答えは両方とも問題に非常にうまく対処しています、私はそこから行くのは良いことだと思います。
ありがとう！

ところで、私は@zvirjaへの追加として私の答えを意味するだけだと言うのを忘れました。 それはすでにそこに良い答えです👍

私はそれを他の方法でとらなかった😄