Autofixture: NCrunchとAutoFixtureの統合の問題

こんにちは、私はNCrunchの開発者です。

これに対する解決策を見つけるためにあなたと協力できれば幸いです。 現在の設計では、残念ながら、統合ポイントの自分の側だけで問題を解決するためのオプションがありません。 現在のデザインで問題を経験したのは私のランナーだけではないと思います。

私が書いたさまざまなドキュメントやサポートフォーラムの投稿から理解できたと思いますが、問題の根本はAutoFixtureによるテストパラメータのランダムな生成にあります。 テストパラメータは、テストを識別して実行する上で重要な要素であるため、テストが構築/検出されるたびにパラメータが変更されると、テストを選択的に実行できなくなります。

この問題を解決するために私が考えることができる唯一の信頼できる方法は、テストパラメーターのランダムな生成をすべて削除し、代わりに固定値（つまり、プレースホルダーまたは定数）を使用するか、パラメーター値のシードをテストケース自体に制限することです。 このように、テストは常にまったく同じであり、他のテストと一貫して同じであることがわかります。 私が扱ったすべてのユーザーは、パラメーター生成にAutoFixtureを使用しましたが、テストの目的で「気にしない」パラメーターについてはそうしました。したがって、このアプローチがユーザーの目には実際の欠点がないことを願っています。 。 これの利点は、NCrunchのすべてのバージョンでもすぐに機能し、NCrunchやその他のランナーのコードを変更する必要がないことです。

@remcomulderここに参加していただきありがとうございます-非常に感謝しています！ 私はそれを少し調査しました、そして私の発見を共有したいと思います。 私の調査結果はすべてxUnitにのみ適用されます。

TL DR： xUnitはそのような理論をサポートしており、NCrunchはxUnitでもそれらをサポートする必要があります。 NUnitの場合、これは未解決の質問であり、まだ調査していません。

私たちが使用している機能は、xUnitの_合法_のようです。 独自のTestDataDiscovererがあり、理論を事前に発見できないことを示しています（ランダムデータを生成するため）。 後で、この検出器ではこの属性を

現在のデザインで問題を経験したのは私のランナーだけではないと思います。

実際、それは真実ではなく、R＃とVSの両方がそのような理論でうまく機能します。 また、自動生成されたデータが含まれている場合でも、特定の理論を再実行することができます。 VSには検出と実行のフェーズも含まれており、オープンソースであるため、VSに焦点を当てることをお勧めします。

次のテストコードを検討してください。

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);
        }
    }
}

.NETFrameworkテストライブラリプロジェクト。 VS2017.3。 ターゲットフレームワーク：4.5.2。 インストールされているパッケージ：

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

VSで検出をトリガーすると、次の出力が表示されます。

お気づきかもしれませんが、データ検出をサポートする理論（ StableInlineTest ）の場合、VSランナーはテストが実行される実際のデータ（ 1 ）を表示します。 データ検出をサポートせず、自動生成されたデータ（ VolatileTest 、 VolatileTestWithInline ）を含むテストの場合、VSは理論のケースを検出せず、理論全体のみを表示します。 実行した後でのみ、この特定の呼び出しの値を確認できます。

これで、特定の理論を再実行でき、_すべての理論ケース_が再度実行されます。

ご覧のとおり、実際にはそのような理論をサポートする方法があり、xUnitはそれを完全に実行します。 NCrunchは、一部の理論ケースを事前に発見できないという事実を考慮に入れる必要があります。 このような理論では、特定のケースではなく、理論全体を再実行する必要があります。 それが不可能な理由がわかりません。

この問題を解決するために私が考えることができる唯一の信頼できる方法は、テストパラメータのランダムな生成をすべて削除し、代わりに固定値（つまり、プレースホルダーまたは定数）を使用することです。

現在、xUnitは、表示名を変更したり、生成されたデータをプレースホルダーに置き換えたりするためのAPIを公開していません。 私は彼らのために問題を作成しました（ここを参照）、しかしブラッドの返事はそれが非現実的であり、彼らは単に私たちがすでに行っている発見を無効にすることを提案しているということです。

または、パラメータ値のシードをテストケース自体に制限します。

残念ながら、現在のところ、これは当社の製品では不可能であり、単一のシードをサポートするために多くのことを書き直す必要があります。

メンバーデータ

ここのドキュメントには、別のサンプルがあります（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));
    }
}

DisableDiscoveryEnumeration属性があるため、xUnitでは絶対に合法です。 上記のサンプルのように機能します-理論上のケースは事前に発見されていません。

結論

xUnitは、テストが揮発性であるかどうかを理解するための手段を提供しているようです（検出前の列挙サポートによって）。 VS実装をサンプルとして使用して、VS実装がそれをどのように処理するかを理解し、製品で同じことを行うことができます。 おそらく、彼らは単にxUnitSDKとそのメッセージシンクを使用しています。

R＃とVSの両方がそのような優れた理論をサポートしていることを考えると、実際にはすべてが私たちの製品で正しいと思います。

NUnitについては、まだ調査していないので、後で説明しましょう。 おそらく、そのようなAPIはありません。

私の調査結果を踏まえて、xUnitサポートに関するご意見をお聞かせください。 のサポートを追加しますか
xUnit（すべてのテストの再実行を停止）と停止して、非互換性の警告を表示しますか？ 😉

ここでお詫びするかもしれません。 上記で説明したユースケースは、説明した理由により、NCrunchで正しく機能します。 Xunitは理論の事前列挙を回避し、それを1つのテストにまとめて、安全に識別して実行します。 これを今テストすると、NCrunchがこれを正しく行うことを確認できます。 InlineAutoDataに明らかな問題はないようです。

なぜこれが以前に失敗したのかわかりません。 私は現在、失敗するシナリオを自分で作成することはできません。 InlineAutoDataが機能していないとユーザーから言われたことは知っていますが、ユーザーが前に出て、これが当てはまる例を提供する必要があると思います。

NCrunchとVSRunnerの両方が壊れることを私が知っている特定のユースケースに注意を向けたいと思います。 ReSharperとTD.NETも破損すると思いますが、インストールしていないため、これらをテストしていません。

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)
        {

        }
    }
}

上記のコードは、すべての選択的実行シナリオで失敗します。 ただし、同じステップでテストが検出されて実行された場合は合格です。 このシナリオは、ユーザーがこれを実行してサポートを求めていたときに、AutoFixtureについてNCrunchによって警告が出された背景にある触媒でした。 AutoFixtureが事前列挙を無効にすることを知らなかったので、InlineAutoDataは同じであると（誤って）想定していました。

私の現在の仮定は、あなたがそのようなシナリオをサポートしていないということです。 これは正しいです？

これを今テストすると、NCrunchがこれを正しく行うことを確認できます。

それは素晴らしいことです！ 実際にxUnitはNCrunchによって完全にサポートされていると聞いてうれしいです🎉NUnitに関しては、常に不器用であり、そこで何ができるかを調査する必要があります。

ただし、NCrunchとAutoFixtureの問題はまだ発生しています。 現在、AutoFixtureを使用したxUnitプロジェクトがあり、1行でも変更すると、すべてのテストが再実行されます。 AutoFixtureを検出すると、このような動作を有効にして、見逃しがないことを確認しているようです。

そうですか？ はいの場合、すべてが正常であるため、xUnitのこのような動作を無効にするように修正してください。

NCrunchとVSRunnerの両方が壊れることを私が知っている特定のユースケースに注意を向けたいと思います。
私の現在の仮定は、あなたがそのようなシナリオをサポートしていないということです。 これは正しいです？

うん、そのシナリオはすべてのランナーを壊します。 ただし、フォーラムのどこかで正しく指摘されているので、AutoFixtureのせいではありません。次のように記述しても機能しない可能性があるため、次のようになります。

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)
    {

    }
}

このようなシナリオでは、事前検出を手動で無効にして、次のようにする必要があります（ 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)
    {

    }
}

我々が持っているとして、実際に、非常にまれなシナリオをすることになっていますAutoDataとInlineAutoDataデータ生成のための属性を。 また、AutoFixtureは単なるツールであり、正しく使用するのは開発者の責任です。

ツールを誤って使用できる人がいるという理由だけで、NCrunchを特別なモードに移行することはしません。 ここでできる最善のことは、既知の問題をどこかに置いて、この特定のシナリオを説明し、xUnitを適切に使用するように人々に依頼することです（彼らはそれについて知らないかもしれません）。

AutoFixtureを検出した場合は、特別な方法でテストを実行していることを確認してください。実行している場合は、xUnitのモードを無効にしてください（NUnitの場合はそのままにしておくことをお勧めします）。 また、このページも更新する必要がある可能性があります。

現時点では、NCrunchは、互換性の警告以外にAutoFixtureの特別な処理を実装していません。 経験した動作は、おそらく選択したエンジンモードが原因です。 完全に構成可能です。「影響を受けるテストを自動的に実行し、他のテストを手動で実行する」モードに切り替えると、エンジンが期待どおりに動作することがわかります。

私があなたから学んだことで、NCrunchからAutoFixture警告を完全に削除する準備ができていると感じています。 警告が広すぎて、AutoFixtureの一部の機能がまだ正しく機能していることが非常に早い段階で明らかになったので、私はすでにユーザーにそれを言い換えるように説得していました。 AutoFixtureがxunitでどのように実装されているかをかなり真剣に誤解していると思います。

したがって、これはおそらく私たちにとって最良のシナリオだと思います。 私を最もひどく壊したユースケースは、とにかく技術的にサポートされておらず、他のすべては正常に機能しています。 その間、熱心な互換性の警告について私を許す原因を見つけることができれば、これをテストして間違った結論に検証したことに対する私自身の恥ずかしさを忘れようとすることを嬉しく思います。

その間、熱心な互換性の警告について私を許す原因を見つけることができれば、これをテストして間違った結論に検証したことに対する私自身の恥ずかしさを忘れようとすることを嬉しく思います。

心配ない！ それは絶対に大丈夫です、そして私たちはお互いが物事を理解するのを助けるためにここにいます😅あなたがチケットをフォローアップして私たちがそれについて話し合ったことは素晴らしいことです-それは多すぎます🥇

私があなたから学んだことで、NCrunchからAutoFixture警告を完全に削除する準備ができていると感じています。

ええと、私たちはまだNUnitに問題を抱えているので（私たちは途中ですが）、このメッセージはNUnitプロジェクトに関連しているように見えます。 おそらく、NUnitの完全なサポート（または少なくともそのサポートを有効にする方法）を導入しない限り、xUnitに対してのみそれを無効にすることは理にかなっています。

まだはっきりしないことが1つあります。 AutoFixture＆NUnitなどをサポートしていないとはどういう意味ですか？ はい、テスト名は毎回異なりますが、すべてのテストを再実行するかどうかは重要ですか（エンジンモードが設定されている場合）？ それとも、「影響のみ」のエンジンをサポートしないということですか？ 私の考えでは、 No supportと言う代わりに、サポートされていない特定のシナリオに絞り込んだほうがよいでしょうが、残りのシナリオは問題ないはずです。

「影響を受けるテストを自動的に実行し、他のテストは手動で実行する」

3.10.0.20インストールでこの設定を見つけることができませんOnly consider tests 'Out of date' if they are 'Impacted'に設定する必要があり、その設定true ？ どこかで見逃してしまったらごめんなさい-私はこの製品に少し慣れていません。

ドキュメントの更新

このページからxUnitとAutoFixtureのケースを_削除_するのではなく、正しく使用する方法を説明することはおそらく理にかなっています（ DisableDiscoveryEnumeration属性を使用してください）。 また、xUnitの「名前が一貫していないNUnitテストケース」のサンプルを説明し、 DisableDiscoveryEnumeration属性をMemberDataAttributeと一緒に使用するように依頼するのもよいでしょう。

まだはっきりしないことが1つあります。 AutoFixture＆NUnitなどをサポートしていないとはどういう意味ですか？ はい、テスト名は毎回異なりますが、すべてのテストを再実行するかどうかは重要ですか（エンジンモードが設定されている場合）？ それとも、「影響のみ」のエンジンをサポートしないということですか？ 私の考えでは、サポートなしと言う代わりに、サポートされていない特定のシナリオに絞り込んだほうがよいでしょうが、残りのシナリオは問題ないはずです。

これは、NCrunchでのテストの寿命が原因です。 NCrunchには、すべてのテストに割り当てられる重要な状態があります（合格/不合格の結果、コードカバレッジデータ、パフォーマンスデータ、トレース出力などを考えてください）。 このデータは、VSのセッション間であっても、テストフレームワークによってテストが「検出」され続ける限り存続します。 テストフレームワークが同じ識別子のテストを報告しない場合、テストは終了したと見なされ、すべての状態が破棄されます。

不安定なパラメーターを使用してテストを作成すると、テストフレームワークを呼び出してテスト結果を検出するたびに、テストの識別子が変更されたため、まったく新しいテストが作成されます。 その結果、NCrunchがNUnitを呼び出してテストを検出するたびに（一貫してテストプロジェクトのビルドごとに）、不安定なパラメーターを使用したテストで保持されていたすべての状態が破棄されます。 だからそれは悪いです。 これは、影響検出が機能せず、エンジンがテストを再実行して一時的な結果をフリックするために大量の追加作業を行うことを意味します。

しかし、問題はさらに深くなります。 テスト状態のダンプが唯一の実際の問題である場合、不安定なテストの処理は、エンジンによって実行され、結果が報告されるという意味で「機能」する可能性があります。 より深刻な問題は、NCrunchの並列化、選択的実行、分散処理に起因します。

並列実行を実行するには、NCrunchはテストを並列に実行する複数のテストプロセスを使用する必要があります。 NUnitの仕組みは、テストを実行する前にテストを検出する必要があるというものです。 つまり、実行に使用される各プロセス内で完全に個別の検出ステップを実行する必要があるため、プロセスが2つある場合は、テストを2回検出する必要があります。 テストのパラメーターが不安定な場合、各プロセスにはまったく異なるテストセットが含まれるため、エンジンがテストの完全なマスターリストをプロセス間で分割して実行することはできません。 リモート実行プロセスは完全に異なる環境の異なるハードウェアで実行されているため、分散処理を使用する場合にもこの問題は拡大します。

選択的実行の問題もあります。 NCrunchのデフォルトの動作モードは、テストを実行するように特に指示されたときに、常に新しいテストプロセスを作成することです。 これは、スレートをクリアし、他のランナーと可能な限り一貫性を保つためです。 新しいテストプロセスを生成するにはテストを再検出する必要があるため、このような機能は不安定なパラメーターでは機能しません。テストは、パラメーターが変更された場合は後で識別できません。

NUnitには、プロセス間で不安定なパラメーターを持つテストを識別するために使用できる独自の内部IDシステムがありますが、このIDシステムはテスト生成シーケンスに基づいています（つまり、増分です）。 このようなシステムは、テストアセンブリの複数のバージョンにわたってテスト状態を管理する必要があるテストランナーは使用できません。ユーザーが新しいテストを作成すると、すべてのIDの順序が狂い、データが危険なほど誤解を招く可能性があるためです。 。 NUnit開発者は、このシーケンスベースのシステムから、テスト属性自体から生成されたIDに移行することに関心を示しています。これは、Xunitが行う方法と似ています（不安定なパラメーターでは機能しない可能性があります）。

これらの問題を解決する最善の方法は、不安定なパラメーターの一貫したシードを実行することであると私は今でも信じています。 テストは繰り返し可能で一貫している必要があるという概念は常にありますが、テストがすべての入力を完全にランダム化している場合、これを達成することは困難です。 実際には、実行のためにランダムにシードされたデータを生成するテストは、コードが供給されるデータに基づいて異なる動作をする可能性があるため、生成されるたびにまったく新しいテストになります。

3.10.0.20のインストールでこの設定を見つけることができませんでした。 trueに設定する必要がある「影響を受ける」設定の場合、「古い」テストのみを検討するという意味ですか？ どこかで見逃してしまったらごめんなさい-私はこの製品に少し慣れていません。

NCrunchメニューに移動し、[エンジンモードの設定]を選択すると、そこにオプションが表示されます。 そこにない場合は、はるかに古いバージョンのNCrunchによって実行されたソリューションを使用していて、レガシーエンジンモードのみが表示されている可能性があります。 どこかに新しいソリューションを作成するだけで、これを解決できます。

@remcomulderうわー！ 詳しい説明ありがとうございます！ 確かに、内部にはいくつかの大きな問題があるため、AutoFixture＆NUnitは現在サポートされていないと言う方が簡単です😅

これらの問題を解決する最善の方法は、不安定なパラメーターの一貫したシードを実行することであると私は今でも信じています。

実際、このPRでは少し違う考えがあります。 安定するようにテスト名を変更したいと思います。 たとえば、次のようなテストが与えられます。

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

テスト名は次のようになります。

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

名前は各検出/実行中常に同じですが、実際の引数値は毎回異なります。

NUnitに関する深い知識がある場合、このアプローチをどのように評価しますか？ それはあなたのために働きますか？ 特定の引数値にバインドするのではなく、理論名を使用することを期待しています。 したがって、テスト名が安定していれば、識別できるので問題はありません。 これを実装する前に確認していただけますか？ ☺️

テストは繰り返し可能で一貫している必要があるという概念は常にありますが、テストがすべての入力を完全にランダム化している場合、これを達成することは困難です。

おそらく、いつか安定したシードをサポートして、同じ引数でテストを再生できるようにする予定ですが、現在はそれからかなり離れているため、現実的ではありません😕むしろ、ユーザーのアサーションは後で理解できるほど正確であると期待しています一部の範囲で入力がランダム化された場合でも、テストが失敗した理由。

NUnitに関する深い知識がある場合、このアプローチをどのように評価しますか？ それはあなたのために働きますか？ 特定の引数値にバインドするのではなく、理論名を使用することを期待しています。 したがって、テスト名が安定していれば、識別できるので問題はありません。 これを実装する前に確認していただけますか？ ☺️

残念ながら、NUnitに関する私の知識は深いものではありません:( NCrunchは基本的に、NUnitが返す名前を取得し、これを使用して識別子を生成します。したがって、理論的には、ソリューションがテストの物理名を変更/安定化する限り、 NUnit APIによって返される場合、ここで問題ないはずです
少なくともNCrunchの場合。

注意すべき点は、ユーザーが同じ署名で複数のテストを作成する可能性があることです。 名前のパラメーターがraw型に削除されている場合、これははるかに可能性が高くなります。 これらのシナリオを知っている限り、おそらくエラーなどでコーディングして、それを思いとどまらせることができます。

@remcomulder更新するためだけに、この問題を最終的に解決できます。

上で説明したように、xUnitフレームワークはネイティブでサポートされています。 ただし、NUnitの場合、揮発性の名前を使用したテストをサポートしていないため、問題は明確ではありませんでした。

最近、PRをマージし、NUnitの安定した名前のサポートを追加する新しいバージョンのAutoFixture（ v3.51.0 ）をリリースしました。 今のところ、ユーザー側からの手動アクションが必要です（ここを参照）が、v4ではすぐに使用できるようにします。

テストしたところ、上記のアプローチを使用した場合、NCrunchは変更されたテストのみを実行でき、正しく機能するようになりました。 あなたの側からのいくつかの行動が必要かどうかはわかりません（例えば、どこかにそれを文書化する）。 また、その新機能をテストして、今は正常に機能するかどうかをお知らせいただければ問題ありませんので、休憩してください😄

@zvirjaこれについて私をループさせてくれてありがとう。 私はこの作品に簡単なテストをしました、そしてそれは私にはしっかりしているように見えます。 テスト名からランダムな要素を削除することで、ランナーはセッション全体で一貫してテストを識別でき、すべてが順調に見えます:)

ユーザーサポートの時間を節約できると思いますが、私には考えがあります。 私たち全員がソフトウェアで見つける問題の1つは、多くの人がツールを手に入れる前にドキュメントを読まないことです。 NUnitで一意の名前の問題を解決する方法についてアドバイスできるようになったので便利ですが、最善のアプローチは常に問題を自動的に解決することです。

デフォルトでは、AutoFixtureはVolatileNameTestMethodBuilderを使用することに注意してください。 私はこれが下位互換性の理由であると認め、これが賢明であることに同意します。 しかし、環境変数を使用してこのデフォルトをオーバーライドできるようにした場合はどうなるでしょうか。 AutoFixtureにVolatileNameTestMethodBuilderを使用させるために環境変数（たとえば、 'AutoFixture.FixedTestNames' == '1'）を指定できれば、ランナーはユーザーが何もしなくてもビルダーを事前に指定できます。 これは、複数のランナーを使用する人々にとってもボーナスになります。ランナーごとに異なるビルダーを暗黙的に使用し（労力を必要とせずに）、両方の世界を最大限に活用できるからです。

どう思いますか？

私はこの作品に簡単なテストをしました、そしてそれは私にはしっかりしているように見えます。

すごい！ 🎉すべてが正常に機能するようになったため、この問題を解決できることを意味します。 ここでのテストと参加に感謝します🥇

どう思いますか？

私は、はるかに優れた、より単純なソリューションにたどり着いたと思います。 FixedNameTestMethodBuilderをv4（次のメジャーリリース）のデフォルト戦略にします。これは、来月または2か月以内にリリースされます。 適切なPRはすでに承認されているので、コードはそこにあります。 したがって、私たちはすぐに問題なく動作し、誰かが揮発性のテスト名を必要とする場合、彼は手動でオプトインし、結果を明確に理解します。

後で、あなたが提案したようなことをすることができます-環境変数/ AppConfigを検査する切り替え戦略を追加しますが、それが本当に必要な場合にのみそれを行うことを好みます。

最終的には、はるかに優れたシンプルなソリューションになったと思います。FixedNameTestMethodBuilderをv4（次のメジャーリリース）のデフォルト戦略にします。これは、来月または2か月以内にリリースされます。

それは私にとって素晴らしい働きをします:)私は幸せです！ すべての努力に感謝します。

かっこいい😉返信とコラボレーションをありがとうございました👍

両側からのアクションはこれ以上必要ないため、これを閉じます。

@remcomulder @zvirjaこの議論（同様の問題を理解するのに役立ちました）と、ここで示した献身は素晴らしいに過ぎません！ 素晴らしい製品をありがとうございました。