Nunit: Permintaan: Tambahkan dukungan pengindeks ke PropertyConstraint

Aku suka gagasan itu.

C# tidak mendukung properti yang diindeks bernama tetapi VB.NET melakukannya. Saya pikir sintaks .Property("Name", index1, ...) harus dicadangkan untuk pengindeks bernama, jadi saya tidak ingin melihatnya digunakan untuk pengindeks default. Saya ingin dapat menghormati bahasa C # dengan tidak mengharuskan orang untuk memasukkan parameter nama.

Apa pendapatmu tentang Has.Item("TEST1").EqualTo("1") atau Has.Index("TEST1").EqualTo("1") ?

@jnm2
Memiliki metode "Item" atau "Indexer" sebagai pintasan memang mudah, tetapi sebenarnya dimungkinkan untuk mengubah nama pengindeks di C#: https://stackoverflow.com/questions/5110403/class-with-indexer-and-property-named -barang

@Ch0senOne Hal ini dimungkinkan untuk mengubah nama. Agar lebih jelas, saya seharusnya mengatakan, tidak mungkin membuat pengindeks non-default di C#. Misalnya, Anda tidak dapat mendeklarasikan dua pengindeks, Anda juga tidak dapat menggunakan nama dari C#.
Memikirkannya, saya khawatir Has.Item("value") akan terlalu membingungkan dengan Contains.Item . Jadi mungkin Has.Index("value") ?

Jadi saya akan mendukung Has.Index("IndexValue") untuk pengindeks default dan Has.Property("PropertyName", indexParams) untuk pengindeks non-default. Has.Property akhirnya akan bekerja untuk pengindeks default juga meskipun hal C# idiomatik yang harus dilakukan adalah menggunakan Has.Index .

Atau jika kita ingin menjadi imut, kita bisa melakukan Has.Index["IndexValue"] dan
Has.Property("PropertyName")[indexparams] ... 😁

Sebenarnya, saya ingin tahu apakah kita bisa lolos dengan Has.Item["AtIndex"] menggunakan sintaks pengindeks untuk menghindari kebingungan dengan Contains.Item("ItemValue") ... tidak yakin apa yang saya pikirkan tentang itu!

Mari kita lihat apa pendapat anggota tim @nunit/framework-team lainnya.

Kami telah menentukan arah untuk menggunakan properti menggunakan lambdas daripada string. Sepertinya waktu mungkin lebih baik dihabiskan untuk itu. Saya menggunakan ponsel saya jadi saya tidak bisa memberikan nomor edisinya.

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

Itu masuk akal untuk Has.Property . Kita bisa lakukan:

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

Saya masih berpikir kita tidak boleh melakukan apa pun dengan Has.Property sampai properti non-default diperlukan, dan untuk saat ini cukup sediakan Has.Index(value1, ...) atau Has.Index[value1, ...] atau Has.Item[value1, ...] untuk pengindeks default yang jauh lebih umum.

Itu dia. Saya setuju dengan Anda tentang pengindeks bernama, yang toh belum diminta.

@jnm2 Sebagai pertimbangan Anda, Anda juga dapat membuat pengindeks multi-kunci. Sebagai contoh

this[string key1, string key2]

Saya bertanya-tanya apakah ada pembaruan tentang masalah ini, atau cara pengujian pengindeks saat ini pada tipe yang tidak mewarisi IEnumerable. Saya kira saya bisa memeriksa KeyNotFoundException yang dilemparkan. Adakah hal lain yang saya abaikan untuk memungkinkan saya memeriksa keberadaan kunci dalam pengindeks?

@crush83 Ya, sintaks index1, ... saya dimaksudkan untuk menunjukkan bahwa kita harus mempertimbangkannya apa pun yang kita lakukan.

Saya tidak suka kunci terminologi kecuali kita berbicara tentang objek yang sebenarnya adalah kamus atau kumpulan kunci. Itu adalah hal-hal dengan pengindeks default, tetapi tidak semua hal dengan pengindeks default memiliki kunci. (Karena Anda menggunakan terminologi ini, mungkin Anda akan menemukan sintaks Contains.Key membantu? Bisakah kami memperbaikinya?)

Tidak ada kemajuan selain apa yang Anda lihat di sini. Kami membutuhkan proposal. Untuk meletakkan sesuatu di luar sana, favorit saya saat ini adalah Has.Item(params object[] indexerArgs) yang akan memanggil pengindeks default tidak peduli apa namanya.
Apakah ini akan melakukan semua yang diminta sejauh ini?

+1

@nunit/framework-team Apakah Anda mendukung API baru berikut?

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

Saya mungkin akan meninggalkan kelas internal IndexerConstraint sampai ada alasan untuk menambahkannya ke API.

Terdengar bagus untukku.

Suara lain yang mendukung, saya hanya ingin fitur ini untuk tes konsol. 🙂

@jnm2 Apakah masalah ini masih ingin diselesaikan oleh tim?

Saya memiliki squiz cepat melalui masalah ini dan karena saya tidak mengerti persis ingin API yang didukung akan terlihat seperti - apakah itu:

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

atau itu:

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

?

Contoh Anda mengambil params object[] begitu juga dengan opsi 2.

Dengan asumsi memilih. 2, apakah array akan diperlukan seolah-olah hanya satu objek yang disediakan, tegaskan bahwa kuncinya ada, 2 parameter - kunci dan nilai? Kombinasi lain (kurang lebih parameter yang diharapkan), gagal?

@Poimen Ya, dan kami sangat menghargai bantuannya!

Array diperlukan karena pengindeks dapat mengambil lebih dari satu argumen. Sebagai contoh:

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

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

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

Anda akan menggunakan Has.Item(42).EqualTo("First indexer") , Has.Item("42").EqualTo("Second indexer") , dan Has.Item(1, 2).EqualTo("Third indexer") .

Lihat, Anda belajar sesuatu yang baru setiap hari - saya berasumsi itu salah ketik, oops :see_no_evil: Saya belum pernah menggunakan pengindeks multi-kunci sebelumnya...

Oke, keren, saya akan mencoba menyusun sesuatu minggu ini.

@jnm2 Saya telah membuat PR untuk masalah ini.

Satu-satunya kekhawatiran yang saya miliki adalah pesan kesalahan yang dihasilkan oleh kode:

Has.Item(42)

Pesan kesalahannya sedikit "retas", tapi saya tidak yakin apa cara terbersih untuk menyelesaikan ini. "Peretasan" adalah:
https://github.com/nunit/nunit/pull/3609/commits/96154ca6402c692cec5e0ae6947f9922e72799fe#diff -ceeee4b8399633f181b6bccd5a39eb32R72

@Poimen Maaf, tidak yakin apa yang Anda maksud. Apa pesannya saat ini, dan apa yang Anda inginkan? Atau apakah Anda mencari saran?

@jnm2 Pesan kesalahan yang muncul adalah:

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

Cara pesan kesalahan dibentuk fungsi StringifyArguments sedikit "retas".

Jadi pertanyaan saya yang diungkapkan dengan buruk adalah lebih jika ada cara yang lebih bersih untuk menghasilkan output pesan yang diinginkan.

@jnm2 Saya pikir saya telah membahas komentar di ulasan (terima kasih untuk mereka). Labelnya mengatakan awaiting:contributor .

Saya tidak yakin apakah ada hal lain yang perlu saya lakukan untuk memberi tahu Anda bahwa saya "selesai" :+1:

Saya pikir kita harus membuatnya sedekat mungkin dengan pesan yang ditampilkan ketika Has.Property tidak dapat menemukan properti. Kita kemudian harus mengganti property dengan default indexer dan mengganti nama properti dengan accepting arguments [42] atau semacamnya. Saya condong ke arah pemikiran bahwa kita harus menggunakan salah satu pembantu pemformatan yang ada seperti MsgUtils.FormatCollection untuk menunjukkan nilai argumen daripada mencantumkan tipe argumen. Misalnya, salah satu argumen mungkin nol dan berfungsi dengan berbagai tipe.

Tidak, itu bagus! Komentar seperti itu di utas PR itu sendiri akan ideal.

Mengingat penegasan:
```c#
Assert.Itu(penguji, Has.Item("wow"));

It producers the message:

Diharapkan: Pengindeks default menerima argumen <>
Tapi adalah: "tidak ditemukan"

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

Ini menghasilkan pesan:

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

Ini dihasilkan menggunakan fungsi MsgUtils.FormatCollection .

Jadi juga lebih cocok dengan pesan Properti, dengan detail tambahan.

Saya sangat menyukai kasus kedua. Kasus pertama masih tampak salah secara semantik bagi saya karena ini menunjukkan tipe argumen alih-alih nilai argumen. Kami hanya memiliki nilai argumen, dan setiap nilai argumen bisa cocok dengan rentang tipe argumen di pengindeks. Ini menyesatkan untuk membuatnya terlihat seperti harus ada pengindeks dengan argumen System.String karena argumen IEnumerable<char> akan bekerja dengan baik.

IEnumerable<char> adalah kasus penggunaan yang aneh...tapi tentu saja, saya mengerti maksudnya.

Jadi, kembali ke - diberikan:
```c#
Assert.Itu(penguji, Has.Item("wow"));

producers the message:

Diharapkan: Pengindeks default menerima argumen < "wow" >
Tapi adalah: "tidak ditemukan"

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

produsen:

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

Pesan 'Diharapkan' tampak hebat bagi saya. Pesan But was: "not found" terlihat sedikit seperti sedang berbicara tentang instance string dengan konten not found , tetapi jika PropertyConstraint berperilaku dengan cara yang sama, menjaganya tetap sama adalah lebih baik bagi saya. Mengubah PropertyConstraint akan berada di luar cakupan PR ini secara default. Kami masih bisa membuat perubahan jika Anda mau dan saya serta orang lain dalam tim kerangka menyetujui perubahan itu.

Ya, saya mencoba membuatnya tidak melakukan ini, tetapi saya tidak dapat menemukan solusi dengan pesan kesalahan. Saya akan menyukainya hanya untuk menjadi:

But was: not found

tetapi pengembalian ConstraintResult memasukkan tanda kutip string di sana.

Untuk referensi versi properti:
```c#
Assert.Itu(penguji, Has.Property("TidakTidakMemilikiIni"));

produces:

Diharapkan: properti NoItDoesNotHaveThis
Tapi adalah:
```
Jadi tidak ada tanda kutip - tetapi mengembalikan tipe - bukan nilai.

Saya tidak yakin apakah mengembalikan kelebihan ConstraintResult akan menjadi solusi?

Saya pikir kita harus tetap berpegang pada apa yang dilakukan PropertyConstraint untuk konsistensi. Menampilkan representasi default dari nilai actual bukanlah hal terburuk ketika pesan yang mengatakan bahwa yang gagal adalah menemukan properti.

Mengembalikan kelas baru yang diturunkan dari ConstraintResult adalah bagaimana batasan lain menyesuaikan ini, ya.

Oke, bagus - terdengar seperti - diberikan:
```c#
Assert.Itu(penguji, Has.Item(42d));

producers:

Diharapkan: Pengindeks default menerima argumen < 42.0d >
Tapi adalah:
```

Ini cocok dengan pesan batasan properti.

@nunit/framework-team dan semuanya, saya berharap resolusi cepat untuk pertanyaan ini karena PR luar biasa @Poimen (https://github.com/nunit/nunit/pull/3609) siap untuk digabungkan.

@Dreamescaper menarik perhatian saya lebih tinggi di utas ini yang saya lupa : Saya khawatir orang akan menulis dan membaca Assert.That(collection, Has.Item("x")); berpikir bahwa Has.Item berarti Contains.Item .
Kami dapat mempertimbangkan untuk menambahkan sesuatu ke pesan kegagalan, tetapi itu tidak akan membantu masalah memahaminya dengan benar saat membaca Has.Item dalam kode sumber:

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

Di sisi lain, saya tidak suka Has.Index(42) atau Has.Index(42).EqualTo(43) yang saya sarankan daripada Item . Instance memiliki item di index. Anda tidak akan mengatakan bahwa instance memiliki indeks dan indeks itu sendiri sama dengan 43. Indeks adalah hal yang Anda masukkan, 42.

Beberapa pilihan

• Gunakan Has.Item . Menyerah pada masalah yang mungkin ditimbulkannya saat membaca kode sumber. Mungkin menambahkan beberapa mitigasi untuk membantu saat menulis kode sumber, seperti dokumen XML dan tip dalam pesan kegagalan.
• Gunakan Has.Index meskipun ada pencampuran terminologi yang canggung.
• Gunakan Has.ItemAt sebagai gantinya. Has.ItemAt(42).EqualTo(43) .

Tunggu, saya baru saja jatuh cinta dengan saran terakhir karena memiliki paralel dengan metode LINQ ElementAt yang diberi indeks dan mengembalikan item.

Apakah semua orang senang dengan Has.ItemAt ? Saran diterima tetapi sekali lagi saya ingin cepat menghargai waktu yang telah didedikasikan @Poimen .

+1 untuk Has.ItemAt :)

Saya setuju dengan Anda bahwa Has.Item berpotensi membingungkan. Saya suka Has.ItemAt tetapi karena Anda menyukai sintaks LINQ, mengapa tidak menggunakan Has.ElementAt ?

Saya tidak yakin tentang ElementAt, karena ini bukan padanan langsung.
Misalnya untuk Dictionary<string,string> ElementAt(0) LINQ akan mengembalikan pasangan pertama, dan Has.ItemTo(0).EqualTo("...") akan gagal, karena tidak ada pengindeks yang menerima bilangan bulat.

@CharliePoole Itu Item karena kami akan memanggil pengindeks pada mungkin semacam koleksi/kamus/pencarian, sedangkan ElementAt dimaksudkan untuk bekerja dalam kueri dan enumerable lain yang belum tentu koleksi . Elemen koleksi biasanya disebut item.

@Dreamescaper Apakah menurut Anda Has.ItemAt(4) dapat membuat orang berpikir itu berfungsi seperti ElementAt , menghitung daripada memanggil pengindeks?

@jnm2
Mungkin bisa, tapi saya tidak tahu opsi yang lebih baik (dan saya pikir itu masih opsi yang jauh lebih baik daripada Has.Item).

@jnm2 sebenarnya saya agak bingung. Masalah ini dimulai tentang Properties dan masih berjudul. Bagaimana Has.Property dan Has.ItemAt berhubungan atau berinteraksi atau membandingkan satu sama lain di mata pengguna?

[Saya menyadari bahwa properti dan Koleksi Item dapat diperlakukan sebagai setara pada tingkat abstraksi tertentu, tetapi saya tidak berpikir itu adalah tingkat abstraksi di mana kebanyakan dari kita biasanya beroperasi. :senyum_imp: ]

Sebagai hal NUnit 4.0, mungkin menyenangkan untuk membahas bagaimana istilah digunakan dalam API dan sedikit membersihkan. Kata "anggota" adalah salah satu yang sering digunakan sebagai setara dengan "Item" tetapi mungkin juga berarti properti, metode atau variabel.

Saya merasa paling nyaman dengan ItemAt lebih dari ElementAt sebagian karena mungkin terlihat seperti kita mendelegasikan atau mengambil pendekatan tertentu yang sama dengan Enumerable.ElementAt . Apa yang sangat mengejutkan saya dengan ElementAt(int index) kurang spesifik tentang cara kerjanya dan lebih banyak fakta bahwa ada preseden untuk sufiks At di BCL, terutama yang terkait dengan parameter bernama index .

Jika Anda menggunakan ini dengan ILookup, setiap indeks dari ILookup mengembalikan beberapa TElements, bukan satu elemen/item. Has.EntryAt bisa menjadi sesuatu yang bekerja dengan koleksi, kamus, dan pencarian multi-elemen-per-indeks. Reaksi awal saya adalah bahwa Has.ItemAt yang mengembalikan IEnumerable<TElement> dari ILookup mungkin cukup dapat dimengerti .

Bagaimana menurut kalian semua? Sulit ketika Anda dapat melihat lebih dari satu hal berfungsi, tetapi preferensi mayoritas di sini mungkin juga membantu menunjukkan nama mana yang paling mudah ditemukan orang. Orang-orang selain @nunit/framework-team, saya tidak bermaksud mengecualikan Anda. Jika Anda menonton dan Anda memiliki perasaan yang kuat, itu adalah titik data yang selalu membantu!

@CharliePoole Has.Property("X") menegaskan bahwa instance memiliki properti non-parameter yang disebut X . Has.ItemAt("X") akan menegaskan bahwa instance memiliki pengindeks default (properti berparameter dengan nama yang tidak relevan dan terkenal) yang dapat menerima parameter string.

Has.Property("X").EqualTo(3) menegaskan bahwa instance memiliki properti non-parameter yang disebut X yang mengembalikan 3 jika Anda memanggil pengakses get non-parameter. Has.ItemAt("X").EqualTo(3) akan menegaskan bahwa instance memiliki pengindeks default (properti berparameter dengan nama yang tidak relevan dan terkenal) yang mengembalikan 3 jika Anda meneruskan string tertentu "X" ke get pengakses.

Apa yang membuat nama pengindeks default tidak relevan adalah bahwa sintaks C#, VB dan F# semua dapat memanggil pengindeks default tanpa menentukan nama. (Jadi istilah 'default.') Sebuah bahasa yang tidak memiliki konsep pengindeks default tetapi memiliki konsep pengindeks bernama harus menentukan nama. Nama pengindeks default biasanya Item , tetapi pengindeks default dapat dinamai sesuatu yang arbitrer dan masih menjadi pengindeks default karena bahasa tersebut masih dapat memanggilnya tanpa menentukan nama. Di C#, Anda akan melakukannya menggunakan atribut [IndexerName("ArbitraryName")] .

@jnm2 Saya benar-benar mengerti semua bahasa C# dll. tentang pengindeks...

Saya pikir ada potensi kebingungan di antara properti

• __being__ pengindeks dari objek yang sebenarnya
• __returning__ objek yang memiliki pengindeks
• __mengembalikan__ koleksi dengan item di dalamnya

Saya menekankan bahwa __you__ tidak akan bingung dan saya mungkin hanya akan berpura-pura ketika berbicara dengan Anda (metode socrates, Anda tahu :wink: ) tetapi saya curiga banyak yang mungkin menganggapnya membingungkan dan Anda akan menjelaskannya kepada orang-orang cukup banyak.

Saya tidak menentang penambahan tetapi saya pikir perbedaan di atas perlu dijabarkan dalam dokumen.

PS: Saya tidak merasa dikucilkan sama sekali. :senyum:

@CharliePoole Pemikiran yang bagus. Bisakah kita mempertimbangkan itu sampai kita menetapkan nama, karena sepertinya itu tidak akan mempengaruhi pilihan antara Has.ItemAt / Has.ElementAt / Has.EntryAt /etc? Atau adakah poin yang saya lewatkan dan Anda mendukung pilihan penamaan tertentu berdasarkan potensi kebingungan ini?

Sejauh ini saya condong ke arah ItemAt . @Dreamescaper , apakah itu masih di tempat Anda juga? @CharliePoole Saya tidak yakin apakah Anda mengekspresikan preferensi untuk ElementAt atau hanya membantu kami memikirkan prosesnya.

Semakin banyak orang yang mengikuti Has.ItemAt / Has.ElementAt / Has.EntryAt /other, semakin besar kepercayaan yang dapat kita miliki pada apa yang menurut orang intuitif. Saya hanya ingin menyebutnya untuk mana saja yang tampaknya memimpin di hari berikutnya atau lebih, karena kita akan kehilangan rilis 3.13 dengan jumlah yang sangat kecil jika kita membutuhkan waktu lebih lama dari itu.

@jnm2 Hanya mencoba memikirkannya sendiri dan mendorong hal yang sama.

WRT pilihan kata, saya bertanya-tanya apakah beberapa kata tertentu akan bekerja paling baik dengan tiga jenis ekspresi yang saya daftarkan dan juga apakah ada kombinasi lain yang perlu dikhawatirkan. Dengan tiga opsi yang saya sebutkan, Anda akan memiliki

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

Jadi saya kira Anda benar bahwa kata-katanya tidak masalah untuk opsi apa pun

Melihat ke arah jangka panjang, saya lebih suka menggunakan pengindeksan aktual dengan tanda kurung siku. Tapi itu akan membutuhkan kompilasi ekspresi kendala daripada pemodelan sebagai satu set kelas.

Saya tahu bahwa ini di atas nilai gaji saya :smile:, tetapi saya pikir saya akan berpadu di sini...

Saya menyukai ItemAt .

Saya menghabiskan waktu, seperti yang disarankan @CharliePoole , memikirkan beberapa kasus penggunaan. Saya sampai pada pemikiran bahwa ElementAt digunakan lebih banyak dalam situasi IEnumerable dan pengindeks bahasa dapat menangani lebih dari sekadar IEnumerable . Saya duduk di pagar ElementAt sebentar, lalu mempertimbangkan:
```c#
Assert.That(..., Has.ElementAt("satu", "dua"));

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

ItemAt di atas terasa lebih alami untuk mengekspresikan beberapa pengindeks nilai.

Saya juga menganggap bahwa tiket awalnya ditujukan untuk hubungan arus pendek untuk kendala properti dan ItemAt cocok dengan narasi itu. (Namun, ini tidak menghalanginya untuk berubah menjadi sesuatu yang lebih/lebih baik/dll, hanya sudut pandang).

Saya juga lebih suka ItemAt , jadi sebut saja mayoritas dan aturan yang mendukung itu

Untuk mencegah kebingungan, mari pastikan bahwa ini didokumentasikan dengan cepat setelah selesai dan disertakan dalam catatan rilis.

@Poimen Re: nilai gaji Anda, jangan meremehkan sejauh mana kita semua mengada-ada saat kita berjalan di sini. Terima kasih telah berbagi pemikiran Anda!

Dan untuk tingkat gaji, karena semua orang di sini mendapat gaji tahunan sekitar $0 bekerja di NUnit, saya pikir kita semua memiliki tingkat gaji yang sama

@Dreamescaper mengajukan pertanyaan bagus lainnya di PR. Baik positif atau negatif, ini seperti memeriksa jumlah daripada memeriksa keberadaan pengindeks:

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

Tampaknya paling aman untuk menghapus batasan Exists sampai kita memiliki lebih banyak waktu untuk memikirkannya. Saya lebih suka membuka masalah terpisah untuk Has.Indexer(typeof(Type1), typeof(Type2), ...) untuk pemeriksaan keberadaan pengindeks, dan Has.ItemAt(arg1, arg2, ...) untuk benar-benar menjalankan pengindeks dan menegaskan hal-hal tentang nilai yang dihasilkan.

Adakah yang keberatan untuk awalnya mengirim Has.ItemAt(3) sebagai tidak menyelesaikan batasan dan Has.ItemAt(3).EqualTo(4) sebagai menyelesaikan?

Has.Indexer masuk akal bagi saya. Saya berasumsi Anda juga akan mendukung Has.Indexer<T>() , Has.Indexer<T1, T2>() , dll. untuk konsistensi dengan batasan lain.

Terima kasih untuk umpan baliknya! Saya memberikan lampu hijau pada permintaan tarik untuk membuat Has.ItemAt(...) tidak lagi menyelesaikan sendiri, dan saya mengajukan https://github.com/nunit/nunit/issues/3690 untuk melacak Has.Indexer untuk menyediakan kemampuan itu.