Nunit: リクエスト：PropertyConstraintにインデクサーのサポートを追加します

私はその考えが好きです。

C＃は名前付きインデックス付きプロパティをサポートしていませんが、VB.NETはサポートしています。 構文.Property("Name", index1, ...)は名前付きインデクサー用に予約する必要があると思うので、デフォルトのインデクサーに使用されるのを見たくありません。 名前パラメーターを渡す必要がないようにすることで、C＃言語を尊重できるようにしたいと思います。

Has.Item("TEST1").EqualTo("1")またはHas.Index("TEST1").EqualTo("1")についてどう思いますか？

@ jnm2
ショートカットとして「Item」または「Indexer」メソッドを使用するのは便利ですが、実際にはC＃でインデクサー名を変更することができます： -アイテム

@ Ch0senOne名前を変更することが可能です。 明確にするために、C＃でデフォルト以外のインデクサーを作成することはできません。 たとえば、2つのインデクサーを宣言したり、C＃から名前を使用したりすることはできません。
考えてみると、 Has.Item("value")はContains.Itemと混同しすぎるのではないかと思います。 だから多分Has.Index("value") ？

したがって、デフォルトのインデクサーにはHas.Index("IndexValue")を、デフォルト以外のインデクサーにはHas.Property("PropertyName", indexParams)を優先します。 Has.Propertyは、慣用的なC＃でHas.Indexを使用することであっても、デフォルトのインデクサーでも機能することになります。

または、かわいくなりたい場合は、 Has.Index["IndexValue"]と
Has.Property("PropertyName")[indexparams] ...😁

実際、 Contains.Item("ItemValue")と混同されないようにするために、インデクサー構文を使用してHas.Item["AtIndex"]を回避できるかどうか疑問に思います...それについてどう思うかわかりません！

他の@nunit / framework-teamメンバーの考えを見てみましょう。

文字列ではなくラムダを使用してプロパティを処理する方向をすでに定義しました。 それに時間を費やしたほうがいいようです。 私は電話をしているので、問題番号を教えられません。

@CharliePoole https://github.com/nunit/nunit/issues/26？

これはHas.Propertyとって意味があります。 私たちにできること：

• Has.Property(_ => _.PropertyName[index1, ...])
• Has.Property(_ => _.PropertyName, index1, ...)

デフォルト以外のプロパティが必要になるまで、 Has.Property何もすべきではないと思います。今のところ、 Has.Index(value1, ...)またはHas.Index[value1, ...]またはHas.Item[value1, ...]提供するだけです。はるかに一般的なデフォルトのインデクサー。

それだ。 とにかく要求されていない名前付きインデクサーについては同意します。

@ jnm2検討のために、マルチキーインデクサーを作成することもできます。 例えば

this[string key1, string key2]

この問題に関する更新があるかどうか、またはIEnumerableを継承しない型でインデクサーをテストする現在の方法があるかどうか疑問に思っています。 KeyNotFoundExceptionがスローされているかどうかを確認できたと思います。 インデクサーにキーが存在するかどうかを確認するために見落としているものは他にありますか？

@ crush83はい、私のindex1, ...構文は、何をするにしてもそれらを考慮する必要があることを示すためのものでした。

実際に辞書またはキー付きコレクションであるオブジェクトについて話しているのでない限り、用語キーは好きではありません。 これらはデフォルトのインデクサーを備えたものですが、デフォルトのインデクサーを備えたすべてのものにキーがあるわけではありません。 （この用語を使用しているので、 Contains.Key構文が役立つと思うかもしれませんか？改善できますか？）

ここに表示されている以外に進歩はありません。 提案が必要です。 何かを出すために、私の現在のお気に入りはHas.Item(params object[] indexerArgs)で、名前に関係なくデフォルトのインデクサーを呼び出します。
これはこれまでに要求されたすべてを実行しますか？

+1

@ nunit / framework-team次の新しいAPIをサポートしますか？

namespace NUnit.Framework
{
    public abstract class Has
    {
        public static ResolvableConstraintExpression Property(string name);

+       public static ResolvableConstraintExpression Item(params object[] indexerArgs);
    }
}

namespace NUnit.Framework.Constraints
{
    public class ConstraintExpression
    {
        public ResolvableConstraintExpression Property(string name);

+       public ResolvableConstraintExpression Item(params object[] indexerArgs);
    }
}

APIに追加する理由があるまで、おそらくIndexerConstraintクラスを内部のままにしておきます。

私にはいいですね。

別の賛成票、私はコンソールテストのためにこの機能が欲しかっただけです。 🙂

@ jnm2この問題はまだチームがやりたいことですか？

私はこの問題について簡単に説明しましたが、サポートされているAPIがどのように表示されるかを正確に理解していないため、次のようになります。

/// obj from the initial post example
Assert.That(obj, Has.Item("TEST1").EqualTo(1).And.Item("TEST2").EqualTo(2));

またはそれは：

Assert.That(obj, Has.Item("TEST1", 1).And.Item("TEST2", 2));

？

あなたの例はparams object[]取るので、オプション2を使用しました。

選択すると仮定します。 2、配列は、1つのオブジェクトが提供されているかのように必要であり、キーが存在することを表明し、2つのパラメーター（キーと値）が必要ですか？ 他の組み合わせ（多かれ少なかれ期待されるパラメータ）、失敗しますか？

@Poimenはい、そして私たちは助けて

インデクサーは複数の引数を取ることができるため、配列が必要です。 例えば：

public string this[int x] => "First indexer";

public string this[string x] => "Second indexer";

public string this[int x, int y] => "Third indexer";

Has.Item(42).EqualTo("First indexer") 、 Has.Item("42").EqualTo("Second indexer") 、およびHas.Item(1, 2).EqualTo("Third indexer")ます。

ほら、あなたは毎日何か新しいことを学びます-私はそれがタイプミスだと思っていました、おっと：see_no_evil：私は以前にマルチキーインデクサーを使う喜びがありませんでした...

わかりました、かっこいい、今週は何かをまとめる方法を見ていきます。

@ jnm2この問題のPRを作成しました。

私が抱えている懸念の1つは、コードによって生成されるエラーメッセージです。

Has.Item(42)

エラーメッセージは少し「ハッキー」ですが、これを解決する最もクリーンな方法がわかりません。 「ハック」は次のとおりです。
https://github.com/nunit/nunit/pull/3609/commits/96154ca6402c692cec5e0ae6947f9922e72799fe#diff -ceeee4b8399633f181b6bccd5a39eb32R72

@Poimen申し訳ありませんが、どういう意味か

@ jnm2表示されるエラーメッセージは次のとおりです。

  Expected: indexer [System.Int32]
  But was:  "not found"

エラーメッセージが形成される方法StringifyArguments関数は少し「ハッキー」です。

したがって、私のひどく表現された質問は、目的のメッセージ出力を生成するよりクリーンな方法があったかどうかということです。

@ jnm2私はレビューのコメントに対処したと思います（彼らに感謝します）。 ラベルにはawaiting:contributorと書かれています。

私が「完了」したことをあなたに知らせるために私がしなければならないことがもっとあるかどうかはわかりません：+1：

Has.Propertyがプロパティを見つけられないときに表示されるメッセージにできるだけ近づける必要があると思います。 次に、 propertyをdefault indexerに置き換え、プロパティ名をaccepting arguments [42]などに置き換える必要があります。 引数の型を一覧表示するのではなく、 MsgUtils.FormatCollectionなどの既存の書式設定ヘルパーの1つを使用して引数の値を表示する必要があると考える傾向があります。 たとえば、引数の1つがnullであり、さまざまなタイプで機能する場合があります。

いいえ、それは素晴らしいです！ PRスレッド自体にそのようなコメントがあれば理想的です。

アサーションが与えられた場合：
`` `c＃
Assert.That（tester、Has.Item（ "wow"））;

It producers the message:

予想：引数を受け入れるデフォルトのインデクサー<>>
しかし、「見つかりませんでした」

Given the assertion:
```c#
Assert.That(tester, Has.Item("wow").EqualTo(1));

それはメッセージを生成します：

Default indexer accepting arguments < "wow" > was not found on NUnit.Framework.Constraints.IndexerConstraintTests+NamedIndexTester.

これは、 MsgUtils.FormatCollection関数を使用して生成されました。

したがって、詳細が追加されたプロパティメッセージとより厳密に一致します。

私は2番目のケースがとても好きです。 最初のケースは、引数値ではなく引数タイプを示しているため、私にはまだ意味的に間違っているように見えます。 引数値のみがあり、各引数値はインデクサーの引数タイプの範囲と一致できます。 IEnumerable<char>引数も同様に機能するため、 System.String引数を持つインデクサーが存在する必要があるように見せかけるのは誤解を招きます。

IEnumerable<char>は風変わりなユースケースです...しかし、確かに、私は要点を理解しています。

だから、戻って-与えられた：
`` `c＃
Assert.That（tester、Has.Item（ "wow"））;

producers the message:

予想：引数を受け入れるデフォルトのインデクサー<"wow">
しかし、「見つかりませんでした」

For numbers it goes into the usual suffix - given:
```c#
Assert.That(tester, Has.Item(42d));

プロデューサー：

  Expected: Default indexer accepting arguments < 42.0d >
  But was:  "not found"

「期待される」というメッセージは、私には素晴らしいと思います。 But was: "not found"メッセージは、内容がnot found文字列インスタンスについて話しているように見えますが、PropertyConstraintが同じように動作する場合は、同じままにしておくことをお勧めします。 PropertyConstraintの変更は、デフォルトではこのPRの範囲外になります。 必要に応じて変更を加えることもできますが、私とフレームワークチームの他の誰かが変更を承認しました。

ええ、私はそれがこれをしないようにしようとしていました、しかし私はエラーメッセージで解決策を見つけることができませんでした。 私はそれがただあることを望んだでしょう：

But was: not found

しかし、 ConstraintResultが返されると、そこに文字列の引用符が挿入されます。

参考までに、プロパティバージョン：
`` `c＃
Assert.That（tester、Has.Property（ "NoItDoesNotHaveThis"））;

produces:

期待：プロパティNoItDoesNotHaveThis
しかし、だった：
`` `
したがって、引用符はありませんが、値ではなく型を返します。

ConstraintResultオーバーロードを返すことが解決策になるかどうかわかりませんでしたか？

一貫性を保つために、PropertyConstraintが行っていることに固執する必要があると思います。 actual値のデフォルト表現を表示することは、失敗したのがプロパティの検索であるというメッセージの場合、最悪の事態ではありません。

ConstraintResultから派生した新しいクラスを返すことは、他の制約がこれをカスタマイズする方法です。

わかりました、素晴らしい-のように聞こえます-与えられた：
`` `c＃
Assert.That（tester、Has.Item（42d））;

producers:

予想：引数を受け入れるデフォルトのインデクサー<42.0d>
しかし、だった：
`` `

これは、プロパティ制約メッセージと一致します。

@Poimenの優れたPRが（https://github.com/nunit/nunit/pull/3609）それ以外の場合はマージする準備ができているので、@ NUnitの/フレームワーク、チームと誰も、私はこの質問への迅速な解決のために願っています。

@Dreamescaperは、私が追跡できなくなったこのスレッドの上位にある私の懸念に注意を向けました。 Has.ItemはContains.Item意味すると考えて、人々がAssert.That(collection, Has.Item("x"));書き込みと読み取りの両方を行うのではないかと心配しています。 。
失敗メッセージに何かを追加することを検討することもできますが、ソースコードでHas.Itemを読み取るときに、それを正しく理解するという問題は解決しません。

  Expected: Default indexer accepting arguments < 42.0d > (Did you mean to use Contains.Item?)

一方、 Item代わりに提案したHas.Index(42)やHas.Index(42).EqualTo(43)は好きではありません。 インスタンスは、インデックスの項目を有しています。 インスタンスにインデックスがあり、インデックス自体が43に等しいとは言えません。インデックスは、渡すもの、42です。

いくつかのオプション

• Has.Itemます。 ソースコードを読むときに発生する可能性のある問題をあきらめます。 XMLドキュメントや失敗メッセージのヒントなど、ソースコードを作成するときに役立ついくつかの緩和策を追加するかもしれません。
• 用語がぎこちなく混ざっているにもかかわらず、 Has.Index使用してください。
• 代わりにHas.ItemAt使用してください。 Has.ItemAt(42).EqualTo(43) 。

最後の提案は、インデックスが与えられてアイテムを返すLINQ ElementAtメソッドと類似しているため、ちょっと待ってください。

みんなHas.ItemAt満足していますか？ 提案は大歓迎ですが、 @ Poimenがすでに捧げてきた時間を尊重したいと思います。

Has.ItemAt +1 :)

Has.Itemが混乱を招く可能性があることに同意します。 私はHas.ItemAtが好きですが、LINQ構文が好きなので、 Has.ElementAt使用してみませんか？

ElementAtは直接同等ではないため、よくわかりません。
たとえば、 Dictionary<string,string> LINQのElementAt（0）は最初のペアを返し、整数を受け入れるインデクサーがないため、Has.ItemTo（0）.EqualTo（ "..."）は失敗します。

@CharliePooleそれは本当に良い考えです。 見つけるのは直感的ではないようですが、なぜそう思うのかわかりません。 Itemは、おそらく何らかのコレクション/辞書/ルックアップでインデクサーを呼び出すので、私はElementAtは、必ずしもコレクションではないクエリやその他の列挙型で機能することを目的としています。 。 コレクション要素は通常、アイテムと呼ばれます。

@Dreamescaper Has.ItemAt(4)は、インデクサーを呼び出すのではなく、列挙して、 ElementAtと同じように機能すると人々に思わせることができると思いますか？

@ jnm2
おそらく可能ですが、より良いオプションはわかりません（そして、Has.Itemよりもはるかに優れたオプションだと思います）。

@ jnm2私は実際には少し混乱しています。 この問題はプロパティに関するものから始まり、今でもそのようにタイトルが付けられています。 Has.PropertyとHas.ItemAtは、ユーザーの目から見て、どのように相互に関連、相互作用、または比較されますか？

[プロパティとコレクションアイテムは、特定の抽象化レベルで同等として扱うことができることを認識していますが、それは私たちのほとんどが通常操作する抽象化レベルではないと思います。 ：smiling_imp：]

NUnit 4.0のこととして、APIで用語がどのように使用されているかを確認し、少しクリーンアップするとよいでしょう。 「メンバー」という言葉は、「アイテム」と同等のものとしてよく使用されますが、プロパティ、メソッド、または変数を意味する場合もあります。

私が最も快適に感じるItemAt以上ElementAt我々は委任または同じ特定のアプローチを取るようにそれが見えるかもしれないので、部分的にEnumerable.ElementAt 。 ElementAt(int index)私を強く印象づけたのは、それがどのように機能するかという詳細ではなく、特にindexという名前のパラメーターに関連付けられたBCLにAtサフィックスの前例があるという事実index 。

これをILookupで使用する場合、ILookupの各インデックスは、単一の要素/アイテムではなく、複数のTElementを返します。 Has.EntryAtは、コレクション、辞書、およびインデックスごとの複数要素のルックアップで機能するものである可能性があります。 私の最初の反応は、ということですHas.ItemAt返すIEnumerable<TElement> ILookupからは、おそらく理解できる十分です。

みなさんはどう思いますか？ 複数のものが機能しているのを見るのは難しいですが、ここでの大多数の好みは、どの名前が人々にとって最も見つけやすいかを示すのにも役立つかもしれません。 @ nunit / framework-team以外の人たち、私はあなたを除外するつもりはありませんでした。 あなたが見ていて、強い気持ちを持っているなら、それは常に役立つデータポイントです！

@CharliePoole Has.Property("X")は、インスタンスにXというパラメータ化されていないプロパティがあることを表明します。 Has.ItemAt("X")は、インスタンスに、文字列パラメーターを受け入れることができるデフォルトのインデクサー（無関係でよく知られている名前を持つパラメーター化されたプロパティ）があることを表明します。

Has.Property("X").EqualTo(3)は、インスタンスにXというパラメータ化されていないプロパティがあり、パラメータ化されていないgetアクセサを呼び出すと3を返すことを表明します。 Has.ItemAt("X").EqualTo(3)インスタンスは、デフォルトのインデクサ（無関係な、よく知られている名前でパラメータプロパティを）持っていると主張するだろう戻ってその3あなたが特定の文字列を渡す場合"X"へのgetアクセサー。

デフォルトのインデクサーの名前を無関係にしているのは、C＃、VB、およびF＃構文はすべて、名前を指定せずにデフォルトのインデクサーを呼び出すことができるということです。 （したがって、「デフォルト」という用語。）デフォルトのインデクサーの概念はないが、名前付きインデクサーの概念がある言語では、名前を指定する必要があります。 デフォルトのインデクサーの名前は通常Itemですが、デフォルトのインデクサーには任意の名前を付けることができますが、これらの言語では名前を指定しなくても呼び出すことができるため、デフォルトのインデクサーのままです。 C＃では、 [IndexerName("ArbitraryName")]属性を使用してこれを実現します。

@ jnm2私は実際にインデクサーに関するすべてのC＃などの言語を理解しています...しかし...

物件間で混乱が生じる可能性があると思います

• __being__実際のオブジェクトのインデクサー
• __returning__インデクサーを持つオブジェクト
• __returning__アイテムを含むコレクション

__you__は混乱しないことを強調します。おそらく、あなたと話しているときだけふりをします（ソクラテス法、y'know：wink ：）が、多くの人が混乱していると思うかもしれません。かなりたくさん。

私はこの追加に反対していませんが、上記の違いをドキュメントで詳しく説明する必要があると思います。

PS：私はまったく排除されているとは感じませんでした。 ：スマイリー：

@CharliePooleよく考えました。 Has.ItemAt / Has.ElementAt / Has.EntryAt / etcの間の選択に影響を与えないように思われるので、名前を決定するまでその考慮事項を表にすることはできますか？ それとも、私が見逃した点があり、この混乱の可能性に基づいて特定の名前の選択をサポートしていますか？

これまでのところ、私はItemAt傾いています。 @Dreamescaper 、それはまだあなたもいるところですか？ @CharliePoole ElementAt好みを表現しているのか、それともプロセスを考えるのを手伝ってくれているのかわかりません

Has.ItemAt / Has.ElementAt / Has.EntryAt / otherでチャイムを鳴らす人が多ければ多いほど、人々が直感的に感じるものに自信を持つことができます。 それよりもはるかに時間がかかると、3.13のリリースをほんの少しだけ逃してしまうので、翌日かそこらでリードしていると思われる方にだけ呼びたいと思います。

@ jnm2自分で考えて、同じように励まそうとしているだけです。

単語の選択について、私は、特定の単語が、私がリストした3種類の表現で最もよく機能するかどうか、また、心配する他の組み合わせがあるかどうか疑問に思いました。 私が言及した3つのオプションを使用すると、

• Has.ItemAt("foo").EqualTo("bar")
• `Has.Property（" Bing "）。With.ItemAt（" foo "）。EqualTo（" bar "）
• `Has.Property（" Bing "）。With.One.EqualTo（" bar "）

だから私はあなたが正しいと思います言葉遣いはどのオプションにも関係ありません

長期的には、角括弧を使用した実際のインデックス作成を使用したいと思います。 ただし、これには、クラスのセットとしてモデル化するのではなく、実際に制約式をコンパイルする必要があります。

私はこれが私の給料等級を超えていることを知っています：smile ：、しかし私はここでチャイムを鳴らすと思いました...

私はItemAt好きです。

@CharliePooleが提案したように、私はいくつかのユースケースを考えながら時間を費やしました。 ElementAtはIEnumerable状況でより多く使用され、言語インデクサーはIEnumerable以上のものを処理できると思いました。 私はしばらくの間ElementAtフェンスに座って、それから考えました：
`` `c＃
Assert.That（...、Has.ElementAt（ "one"、 "two"））;

against:
```c#
Assert.That(..., Has.ItemAt("one", "two"));

ItemAtは、複数の値のインデクサーを表現する方が自然だと感じています。

私はまた、チケットはもともとプロパティの制約のための短絡を意図しており、 ItemAtはその物語に適合していると考えました。 （ただし、これは、より良い/より良い/などに変形することを排除するものではなく、単なる視点です）。

私もItemAt好きなので、それを過半数と呼び、それを支持して支配しましょう😺

混乱を防ぐために、これが完了後すぐに文書化され、リリースノートに含まれるようにしましょう。

@Poimen Re：あなたの給料等級、私たちがここに沿って進むにつれて、私たち全員が物事を作り上げている程度を過小評価しないでください。 あなたの考えを共有してくれてありがとう！

そして、賃金等級に関しては、ここの誰もがNUnitに取り組んで約$ 0の年俸を稼いでいるので、私たちは皆同じ賃金等級にいると思います😝

@DreamescaperはPRで別の良い質問をしました。 正か負かにかかわらず、これはインデクサーの存在をチェックするのではなく、カウントをチェックするのと同じです。

Assert.That(new[] { 1, 2, 2 }, Has.ItemAt(3));
Assert.That(new[] { 1, 2, 2 }, Has.No.ItemAt(3));

考える時間が増えるまで、Exists制約を削除するのが最も安全なようです。 インデクサーの存在チェックのためにHas.Indexer(typeof(Type1), typeof(Type2), ...)別の問題を開き、実際にインデクサーを実行して結果の値について主張するためにHas.ItemAt(arg1, arg2, ...)を開くことをお勧めします。

制約を解決しないとして最初にHas.ItemAt(3)を出荷し、解決するとしてHas.ItemAt(3).EqualTo(4)を出荷することに反対する人はいますか？

Has.Indexerは私には理にかなっています。 他の制約との一貫性を保つために、 Has.Indexer<T>() 、 Has.Indexer<T1, T2>()などもサポートすると思います。

フィードバックをお寄せいただきありがとうございます！ Has.ItemAt（...）を自己解決しないようにするために、プルリクエストでゴーサインを出し、 Has.Indexerを追跡するためにhttps://github.com/nunit/nunit/issues/3690を提出しましたHas.Indexerその機能を提供するための