Nunit: Funktionsvorschlag: Unterstützung von Indexern zur PropertyConstraint hinzufügen

Ich mag die Idee.

C# unterstützt keine benannten indizierten Eigenschaften, aber VB.NET tut dies. Ich denke, die Syntax .Property("Name", index1, ...) sollte für benannte Indexer reserviert sein, daher möchte ich nicht, dass dies für einen Standardindexer verwendet wird. Ich möchte in der Lage sein, die C#-Sprache zu respektieren, indem ich nicht auffordere, dass die Leute einen Namensparameter übergeben.

Was halten Sie von Has.Item("TEST1").EqualTo("1") oder Has.Index("TEST1").EqualTo("1") ?

@jnm2
Es ist praktisch, die Methode "Item" oder "Indexer" als Verknüpfung zu verwenden, aber es ist tatsächlich möglich, den Indexernamen in C# zu ändern: https://stackoverflow.com/questions/5110403/class-with-indexer-and-property-named -Artikel

@Ch0senOne Es ist möglich, den Namen zu ändern. Klarer gesagt, es ist nicht möglich, in C# einen nicht standardmäßigen Indexer zu erstellen. Sie können beispielsweise weder zwei Indexer deklarieren noch den Namen aus C# verwenden.
Wenn ich darüber nachdenke, fürchte ich, dass Has.Item("value") zu verwechselbar wäre mit Contains.Item . Also vielleicht Has.Index("value") ?

Also würde ich Has.Index("IndexValue") für den Standardindexer und Has.Property("PropertyName", indexParams) für Nicht-Standardindexer befürworten. Has.Property würde am Ende auch für Standardindexer funktionieren, obwohl die idiomatische C#-Sache darin besteht, Has.Index .

Oder wenn wir süß sein wollten, könnten wir Has.Index["IndexValue"] und
Has.Property("PropertyName")[indexparams] ...

Eigentlich frage ich mich, ob wir mit Has.Item["AtIndex"] durch die Indexer-Syntax davonkommen könnten, um eine Verwechslung mit Contains.Item("ItemValue") zu vermeiden ... ich bin mir nicht sicher, was ich davon halte!

Mal sehen, was die anderen @nunit/framework-team-Mitglieder denken.

Wir haben bereits eine Richtung für Eigenschaften definiert, die Lambdas anstelle von Strings verwendet. Scheint so, als ob die Zeit besser dafür verwendet werden könnte. Ich telefoniere und kann Ihnen die Nummer des Problems nicht geben.

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

Das macht Sinn für Has.Property . Wir könnten:

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

Ich denke immer noch, dass wir nichts mit Has.Property bis nicht standardmäßige Eigenschaften benötigt werden, und im Moment einfach Has.Index(value1, ...) oder Has.Index[value1, ...] oder Has.Item[value1, ...] für die . bereitstellen weitaus häufigere Standardindexer.

Das ist der eine. Ich stimme Ihnen bei benannten Indexern zu, die sowieso nicht angefordert wurden.

@jnm2 Zu Ihrer Überlegung können Sie auch einen Indexer mit mehreren Schlüsseln erstellen. Beispielsweise

this[string key1, string key2]

Ich frage mich, ob es ein Update zu diesem Problem oder eine aktuelle Methode zum Testen von Indexern für einen Typ gibt, der IEnumerable nicht erbt. Ich nehme an, ich könnte einfach überprüfen, ob eine KeyNotFoundException ausgelöst wird. Alles andere, was ich übersehe, um zu überprüfen, ob ein Schlüssel in einem Indexer vorhanden ist?

@crush83 Ja, meine index1, ... Syntax sollte darauf hinweisen, dass wir sie bei allem berücksichtigen sollten, was wir tun.

Ich weiß nicht , wie die Terminologie Schlüssel , wenn wir nicht über ein Objekt sprechen , die tatsächlich ein Wörterbuch oder Schlüssel Sammlung ist. Das sind Dinge mit Standardindexern, aber nicht alle Dinge mit Standardindexern haben Schlüssel. (Da Sie diese Terminologie verwenden, finden Sie vielleicht unsere Contains.Key Syntax hilfreich? Können wir sie verbessern?)

Es gab keine anderen Fortschritte als das, was Sie hier sehen. Wir brauchen einen Vorschlag. Um etwas herauszubringen, mein derzeitiger Favorit ist Has.Item(params object[] indexerArgs) der den Standardindexer aufrufen würde, egal wie er heißt.
Würde dies alles tun, was bisher verlangt wurde?

+1

@nunit/framework-team Würden Sie die folgende neue API unterstützen?

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

Ich würde die Klasse IndexerConstraint wahrscheinlich intern lassen, bis es einen Grund gibt, sie der API hinzuzufügen.

Klingt gut für mich.

Noch eine Stimme dafür, ich wollte diese Funktion nur für einen Konsolentest. 🙂

@jnm2 Ist dieses Problem immer noch etwas, das das Team erledigen möchte?

Ich hatte ein kurzes Squiz durch das Problem und da ich es nicht genau verstehe, sollte die unterstützte API so aussehen - ist es:

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

oder ist es:

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

?

Ihr Beispiel nimmt params object[] also ging ich mit Option 2.

Vorausgesetzt, opt. 2, wäre das Array erforderlich, als ob nur ein Objekt bereitgestellt würde, behaupten, dass der Schlüssel existiert, 2 Parameter - Schlüssel und Wert? Andere Kombinationen (mehr oder weniger erwartete Parameter) schlagen fehl?

@Poimen Ja, und wir würden uns über Hilfe

Das Array ist erforderlich, da Indexer mehr als ein Argument annehmen können. Beispielsweise:

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

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

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

Sie würden Has.Item(42).EqualTo("First indexer") , Has.Item("42").EqualTo("Second indexer") und Has.Item(1, 2).EqualTo("Third indexer") .

Sehen Sie, Sie lernen jeden Tag etwas Neues - ich hatte das für einen Tippfehler gehalten, oops :see_no_evil: Ich hatte noch nie das Vergnügen, einen Multikey-Indexer zu verwenden ...

Ok, cool, ich werde mir diese Woche mal etwas zusammenstellen.

@jnm2 Ich habe eine PR für dieses Problem erstellt.

Die einzige Sorge, die ich habe, ist die Fehlermeldung, die vom Code erzeugt wird:

Has.Item(42)

Die Fehlermeldung ist ein wenig "hacky", aber ich bin mir nicht sicher, wie das am saubersten gelöst werden kann. Der "Hack" ist:
https://github.com/nunit/nunit/pull/3609/commits/96154ca6402c692cec5e0ae6947f9922e72799fe#diff -ceeee4b8399633f181b6bccd5a39eb32R72

@Poimen Entschuldigung, ich

@jnm2 Die

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

Die Art und Weise, wie die Fehlermeldungen gebildet werden StringifyArguments Funktion ist ein wenig "hacky".

Meine schlecht formulierte Frage ist also eher, ob es einen saubereren Weg gäbe, die gewünschte Nachrichtenausgabe zu erzeugen.

@jnm2 Ich glaube, ich habe die Kommentare zur Rezension angesprochen (danke dafür). Auf dem Etikett steht awaiting:contributor .

Ich bin mir nicht sicher, ob ich noch etwas tun muss, um Sie wissen zu lassen, dass ich "fertig" bin :+1:

Ich denke, wir sollten es so nah wie möglich an der Meldung machen, die angezeigt wird, wenn Has.Property eine Eigenschaft nicht finden kann. Wir sollten dann property durch default indexer und den Eigenschaftsnamen durch accepting arguments [42] oder so ähnlich ersetzen. Ich neige dazu zu denken, dass wir einen der vorhandenen Formatierungshelfer wie MsgUtils.FormatCollection , um die Argumentwerte anzuzeigen, anstatt die Argumenttypen aufzulisten. Beispielsweise kann eines der Argumente null sein und mit einer Reihe von Typen funktionieren.

Nein, das ist großartig! Ein solcher Kommentar im PR-Thread selbst wäre ideal.

Angesichts der Behauptung:
```c#
Assert.That(Tester, Has.Item("wow"));

It producers the message:

Erwartet: Standardindexer akzeptiert Argumente <>
Aber war: "nicht gefunden"

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

Es produziert die Botschaften:

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

Dies wurde mit der Funktion MsgUtils.FormatCollection generiert.

Passt also auch besser zu den Property-Meldungen mit den hinzugefügten Details.

Der zweite Fall gefällt mir sehr gut. Der erste Fall erscheint mir immer noch semantisch falsch, da er Argumenttypen anstelle von Argumentwerten anzeigt. Wir haben nur Argumentwerte, und jeder Argumentwert kann mit einer Reihe von Argumenttypen im Indexer übereinstimmen. Es ist irreführend, es so aussehen zu lassen, als müsste es einen Indexer mit einem System.String Argument geben, weil ein IEnumerable<char> Argument genauso gut funktionieren würde.

IEnumerable<char> ist ein verrückter Anwendungsfall ... aber klar, ich verstehe den Punkt.

Also zurück zu - gegeben:
```c#
Assert.That(Tester, Has.Item("wow"));

producers the message:

Erwartet: Standardindexer akzeptiert Argumente < "wow" >
Aber war: "nicht gefunden"

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

Hersteller:

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

Die Nachricht "Erwartet" sieht dann für mich großartig aus. Die Nachricht But was: "not found" sieht ein wenig so aus, als würde sie über eine Zeichenfolgeninstanz mit dem Inhalt not found sprechen, aber wenn sich PropertyConstraint genauso verhält, ist es mir vorzuziehen, sie gleich zu lassen. Das Ändern von PropertyConstraint wäre für diese PR standardmäßig nicht möglich. Wir könnten immer noch eine Änderung vornehmen, wenn Sie wollten, und ich und jemand anderes im Framework-Team haben der Änderung zugestimmt.

Ja, ich habe versucht, dies nicht zu tun, aber ich konnte mit der Fehlermeldung keine Lösung finden. Ich hätte es gerne einfach so gehabt:

But was: not found

aber die Rückgabe von ConstraintResult setzt dort die String-Anführungszeichen.

Als Referenz die Eigenschaftsversion:
```c#
Assert.That(Tester, Has.Property("NoItDoesNotHaveThis"));

produces:

Erwartet: Eigenschaft NoItDoesNotHaveThis
Aber war:
```
Es gibt also keine Anführungszeichen - aber es gibt den Typ zurück - keinen Wert.

Ich war mir nicht sicher, ob die Rückgabe einer Überladung von ConstraintResult eine Lösung wäre?

Ich denke, wir sollten uns an das halten, was PropertyConstraint für Konsistenz tut. Das Anzeigen der Standarddarstellung des actual Werts ist nicht das Schlimmste, wenn die Meldung besagt, dass das Finden der Eigenschaft fehlgeschlagen ist.

Das Zurückgeben einer neuen Klasse, die von ConstraintResult abgeleitet ist, ist, wie andere Einschränkungen dies anpassen, ja.

Ok, toll - klingt wie - gegeben:
```c#
Assert.That(Tester, Has.Item(42d));

producers:

Erwartet: Standardindexer akzeptiert Argumente < 42.0d >
Aber war:
```

Dies stimmt mit der Eigenschaftseinschränkungsnachricht überein.

@nunit/framework-team und alle, ich hoffe auf eine schnelle Lösung dieser Frage, da @Poimens ausgezeichnete PR (https://github.com/nunit/nunit/pull/3609) bereit ist, anderweitig zusammenzufügen.

@Dreamescaper hat mich weiter oben in diesem Thread auf ich aus den Augen verloren habe: Ich fürchte, die Leute schreiben und lesen Assert.That(collection, Has.Item("x")); denken, dass Has.Item Contains.Item .
Wir könnten erwägen, der Fehlermeldung etwas hinzuzufügen, aber das wird das Problem des richtigen Verständnisses beim Lesen von Has.Item im Quellcode nicht verbessern:

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

Auf der anderen Seite mag ich Has.Index(42) oder Has.Index(42).EqualTo(43) , was ich anstelle von Item . Die Instanz hat ein Element an einem Index. Sie würde nicht sagen , die Instanz einen Index hat und dass der Index sich auf 43 gleich ist der Index ist , was Sie in, 42 passieren.

Einige der Optionen

• Verwenden Sie Has.Item . Geben Sie die Probleme auf, die es beim Lesen des Quellcodes verursachen könnte. Fügen Sie möglicherweise einige Abschwächungen hinzu, um beim Schreiben von Quellcode zu helfen, z. B. XML-Dokumente und Tipps in Fehlermeldungen.
• Verwenden Sie Has.Index trotz der umständlichen Vermischung der Terminologie.
• Verwenden Sie stattdessen Has.ItemAt . Has.ItemAt(42).EqualTo(43) .

Moment, ich habe mich gerade in den letzten Vorschlag verliebt, da er eine Parallele zur LINQ ElementAt-Methode hat, die einen Index erhält und ein Element zurückgibt.

Sind alle mit Has.ItemAt zufrieden? Vorschläge willkommen, aber ich möchte die Zeit, die @Poimen bereits gewidmet hat, schnell respektieren.

+1 für Has.ItemAt :)

Ich stimme Ihnen zu, dass Has.Item potenziell verwirrend ist. Ich mag Has.ItemAt aber da Sie die LINQ-Syntax mögen, warum nicht Has.ElementAt ?

Bei ElementAt bin ich mir nicht sicher, da es kein direktes Äquivalent ist.
ZB für Dictionary<string,string> gibt ElementAt(0)

@CharliePoole Das ist ein wirklich guter Gedanke. Es scheint, als wäre es nicht so intuitiv zu finden, aber ich weiß nicht, warum ich das denke. Ich denke, ich bevorzuge Item weil wir einen Indexer für vermutlich eine Sammlung/ein Wörterbuch/eine Suche aufrufen, während ElementAt in Abfragen und anderen Aufzählungen funktionieren soll, die nicht unbedingt Sammlungen sind . Sammlungselemente werden normalerweise als Elemente bezeichnet.

@Dreamescaper Glaubst du, Has.ItemAt(4) könnte die Leute denken lassen, dass es genau wie ElementAt funktioniert, indem man einen Indexer aufzählt, anstatt ihn aufzurufen?

@jnm2
Es könnte wahrscheinlich, aber ich kenne keine bessere Option (und ich denke, es ist immer noch eine viel bessere Option als Has.Item).

@jnm2 Ich bin eigentlich etwas verwirrt. In dieser Ausgabe ging es zunächst um Eigenschaften und wird immer noch so betitelt. Wie werden Has.Property und Has.ItemAt aus Sicht des Nutzers miteinander in Beziehung stehen bzw. interagieren oder miteinander vergleichen?

[Mir ist klar, dass Eigenschaften und Sammlungselemente auf einer bestimmten Abstraktionsebene als gleichwertig behandelt werden können, aber ich glaube nicht, dass dies die Abstraktionsebene ist, auf der die meisten von uns normalerweise arbeiten. :smiling_imp: ]

Als eine Sache von NUnit 4.0 könnte es schön sein, die Verwendung von Begriffen in der API durchzugehen und ein wenig aufzuräumen. Das Wort "Mitglied" wird oft als Äquivalent zu "Element" verwendet, kann aber auch Eigenschaft, Methode oder Variable bedeuten.

Ich fühle mich am wohlsten mit ItemAt über ElementAt teilweise weil es so aussieht, als würden wir an Enumerable.ElementAt delegieren oder denselben speziellen Ansatz ElementAt(int index) waren weniger die Besonderheiten der Funktionsweise als vielmehr die Tatsache, dass es Präzedenzfälle für At Suffixe in der BCL gibt, insbesondere in Verbindung mit einem Parameter namens index .

Wenn Sie dies mit einem ILookup verwenden, gibt jeder Index eines ILookup mehrere TElements zurück, nicht ein einzelnes Element/Element. Has.EntryAt könnte etwas sein, das mit Sammlungen, Wörterbüchern und Suchvorgängen mit mehreren Elementen pro Index funktioniert. Meine erste Reaktion ist, dass Has.ItemAt , die IEnumerable<TElement> von einem ILookup zurückgibt, wahrscheinlich verständlich genug ist .

Was meint ihr alle? Es ist schwierig, wenn Sie sehen, dass mehr als eine Sache funktioniert, aber die Mehrheitspräferenz hier kann auch helfen, anzugeben, welcher Name für die Leute am einfachsten zu finden ist. Leute außer @nunit/framework-team, ich wollte euch nicht ausschließen. Wenn Sie zuschauen und ein starkes Gefühl haben, ist dies ein Datenpunkt, der immer hilfreich ist!

@CharliePoole Has.Property("X") , dass die Instanz eine nicht parametrisierte Eigenschaft namens X . Has.ItemAt("X") würde behaupten, dass die Instanz einen Standardindexer (eine parametrisierte Eigenschaft mit einem irrelevanten, bekannten Namen) hat, der einen Zeichenfolgenparameter akzeptieren kann.

Has.Property("X").EqualTo(3) , dass die Instanz eine nicht parametrisierte Eigenschaft namens X , die 3 zurückgibt, wenn Sie ihren nicht parametrisierten get Accessor aufrufen. Has.ItemAt("X").EqualTo(3) würde behaupten, dass die Instanz einen Standardindexer hat (eine parametrisierte Eigenschaft mit einem irrelevanten, bekannten Namen), der 3 zurückgibt, wenn Sie die spezifische Zeichenfolge "X" an seine . übergeben get Accessor.

Was den Namen des Standardindexers irrelevant macht, ist, dass die C#-, VB- und F#-Syntax Standardindexer aufrufen kann, ohne einen Namen anzugeben. (Daher der Begriff 'Standard'.) Eine Sprache, die kein Konzept von Standardindexern, aber ein Konzept von benannten Indexern hatte, müsste den Namen angeben. Der Name des Standardindexers ist normalerweise Item , aber der Standardindexer kann einen beliebigen Namen haben und dennoch der Standardindexer sein, da diese Sprachen ihn immer noch ohne Angabe eines Namens aufrufen könnten. In C# erreichen Sie dies mit dem Attribut [IndexerName("ArbitraryName")] .

@jnm2 Ich verstehe eigentlich alle C# usw.-Sprachsachen über Indexer ... jedoch ...

Ich denke, es besteht Verwechslungsgefahr zwischen der Unterkunft

• __sein__ ein Indexer des tatsächlichen Objekts
• __zurückgeben__ ein Objekt, das einen Indexer hat
• __returning__ eine Sammlung mit Gegenständen darin

Ich betone, dass __Sie__ nicht verwirrt sein werden und ich wahrscheinlich nur so tun werde, als ob ich mit Ihnen rede (sokratische Methode, weißt du :wink: ), aber ich vermute, viele finden es verwirrend und Sie werden es den Leuten erklären ziemlich viel.

Ich bin nicht gegen den Zusatz, aber ich denke, die obigen Unterschiede müssten in den Dokumenten aufgeführt werden.

PS: Ich habe mich überhaupt nicht ausgeschlossen gefühlt. :smiley:

@CharliePoole Guter Gedanke. Können wir diese Überlegungen anstellen, bis wir uns auf einen Namen geeinigt haben, da es sich so anhört, als würde es die Wahl zwischen Has.ItemAt / Has.ElementAt / Has.EntryAt /etc nicht beeinflussen? Oder habe ich einen Punkt übersehen und Sie unterstützen eine bestimmte Namenswahl aufgrund dieses Verwirrungspotentials?

Bisher tendiere ich zu ItemAt . @Dreamescaper , bist du auch noch da? @CharliePoole Ich war mir nicht sicher, ob Sie ElementAt bevorzugen oder uns nur beim Durchdenken des Prozesses helfen.

Je mehr Leute sich bei Has.ItemAt / Has.ElementAt / Has.EntryAt /other einmischen, desto mehr Vertrauen können wir in das haben, was die Leute intuitiv finden. Ich würde es gerne für das nennen, was am nächsten Tag oder so an der Spitze zu sein scheint, da wir die Version 3.13 so winzig verpassen werden, wenn wir viel länger brauchen.

@jnm2 Ich versuche nur, es selbst zu durchdenken und dasselbe zu ermutigen.

Bei der Wortwahl habe ich mich gefragt, ob eine bestimmte Formulierung mit den drei von mir aufgeführten Ausdrucksarten am besten funktioniert und ob es andere Kombinationen gibt, über die man sich Gedanken machen muss. Mit den drei Optionen, die ich erwähnt habe, hätten Sie

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

Also ich denke du hast recht, dass die Formulierung für alle Optionen keine Rolle spielt

Längerfristig würde ich eher die tatsächliche Indizierung mit eckigen Klammern verwenden. Dies würde jedoch erfordern, den Einschränkungsausdruck tatsächlich zu kompilieren, anstatt als eine Menge von Klassen zu modellieren.

Ich weiß, dass das über meiner Gehaltsklasse liegt :smile:, aber ich dachte, ich melde mich hier...

Ich mag ItemAt .

Ich habe, wie @CharliePoole vorgeschlagen hat, Zeit damit verbracht, einige Anwendungsfälle ElementAt in IEnumerable Situationen häufiger verwendet wird und die Sprachindexer mehr als nur IEnumerable . Ich saß eine Weile auf dem ElementAt Zaun und überlegte dann:
```c#
Assert.That(..., Has.ElementAt("eins", "zwei"));

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

ItemAt im Obigen fühlt sich natürlicher an, um mehrere Value-Indexer auszudrücken.

Ich dachte auch, dass das Ticket ursprünglich für einen Kurzschluss wegen einer Eigentumsbeschränkung gedacht war und ItemAt zu dieser Erzählung passt. (Dies schließt jedoch nicht aus, dass es sich in etwas mehr / besseres / usw. verwandelt, nur ein Standpunkt).

Ich bevorzuge auch ItemAt , also nennen wir es Mehrheit und entscheiden dafür 😺

Um Verwirrung zu vermeiden, stellen wir sicher, dass dies nach Abschluss schnell dokumentiert und in die Versionshinweise aufgenommen wird.

@Poimen Re: Ihre ausdenken , während wir hier

Und was die Gehaltsgruppe betrifft, da jeder hier ein Jahresgehalt von etwa 0 US-Dollar mit NUnit verdient, denke ich, dass wir alle die gleiche Gehaltsklasse haben 😝😝

@Dreamescaper hat in der PR eine weitere gute Frage gestellt. Ob positiv oder negativ, dies würde so aussehen, als würde die Anzahl überprüft, anstatt auf das Vorhandensein eines Indexers zu prüfen:

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

Es scheint am sichersten, die Einschränkung Exists zu entfernen, bis wir mehr Zeit haben, darüber nachzudenken. Ich würde es vorziehen, ein separates Issue für Has.Indexer(typeof(Type1), typeof(Type2), ...) für eine Indexer-Existenzprüfung zu öffnen und Has.ItemAt(arg1, arg2, ...) , um den Indexer tatsächlich auszuführen und Dinge über den resultierenden Wert zu bestätigen.

Würde jemand etwas dagegen haben, Has.ItemAt(3) als nicht auflösend zu einer Einschränkung und Has.ItemAt(3).EqualTo(4) als auflösend zu versenden?

Has.Indexer macht für mich Sinn. Ich gehe davon aus, dass Sie auch Has.Indexer<T>() , Has.Indexer<T1, T2>() usw. aus Gründen der Konsistenz mit anderen Einschränkungen unterstützen würden.

Danke für die Rückmeldung! Ich habe der Pull-Anfrage grünes Licht gegeben, damit Has.ItemAt(...) nicht mehr selbstauflösend ist, und ich habe https://github.com/nunit/nunit/issues/3690 eingereicht, um Has.Indexer zu verfolgen