Nunit: 기능요청: PropertyConstraint에 인덱서 지원 추가

아이디어가 마음에 듭니다.

C#은 명명된 인덱싱된 속성을 지원하지 않지만 VB.NET은 지원합니다. .Property("Name", index1, ...) 구문은 명명된 인덱서용으로 예약되어야 하므로 기본 인덱서에 사용되는 것을 보고 싶지 않습니다. 사람들이 이름 매개변수를 전달하도록 요구하지 않음으로써 C# 언어를 존중할 수 있기를 바랍니다.

Has.Item("TEST1").EqualTo("1") 또는 Has.Index("TEST1").EqualTo("1") 어떻게 생각하세요?

@jnm2
"Item" 또는 "Indexer" 메서드를 바로 가기로 사용하면 편리하지만 실제로 C#에서 인덱서 이름을 변경할 수 있습니다. https://stackoverflow.com/questions/5110403/class-with-indexer-and-property-named -안건

@Ch0senOne 이름 변경이 가능합니다. 분명히 말했어야 했는데 C#에서 기본이 아닌 인덱서를 만드는 것은 불가능합니다. 예를 들어 두 개의 인덱서를 선언할 수 없으며 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, 하나의 객체만 제공된 것처럼 배열이 필요합니까, 키가 존재하는지, 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") 합니다.

보세요, 당신은 매일 새로운 것을 배웁니다 - 나는 그것이 오타라고 생각했습니다, oops :see_no_evil: 전에는 다중 키 인덱서를 사용하는 즐거움을 느껴본 적이 없었습니다...

알겠습니다. 이번 주에 정리할 내용을 살펴보겠습니다.

@jnm2 이 문제에 대한 PR을 만들었습니다.

내가 가진 한 가지 우려는 코드에서 생성되는 오류 메시지입니다.

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 와 같은 기존 형식 지정 도우미 중 하나를 사용해야 한다고 생각합니다. 예를 들어, 인수 중 하나가 null이고 다양한 유형에서 작동할 수 있습니다.

아니오, 훌륭합니다! PR 스레드 자체에 그런 코멘트가 이상적일 것입니다.

주장을 감안할 때 :
```c#
Assert.That(테스터, Has.Item("와우"));

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 함수를 사용하여 생성되었습니다.

따라서 추가된 세부 정보와 함께 속성 메시지와 더 밀접하게 일치합니다.

나는 두 번째 경우를 매우 좋아한다. 첫 번째 경우는 인수 값 대신 인수 유형을 표시하기 때문에 여전히 의미상 잘못된 것 같습니다. 인수 값만 있으며 각 인수 값은 인덱서의 인수 유형 범위와 일치할 수 있습니다. IEnumerable<char> 인수도 마찬가지로 작동하기 때문에 System.String 인수가 있는 인덱서가 있는 것처럼 보이게 하는 것은 잘못된 것입니다.

IEnumerable<char> 는 엉뚱한 사용 사례입니다...하지만 확실히 요점은 알겠습니다.

그래서, 다시 주어진:
```c#
Assert.That(테스터, Has.Item("와우"));

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(테스터, Has.Property("NoItDoesNotHaveThis"));

produces:

예상: 속성 NoItDoesNotHaveThis
하지만 다음과 같았습니다.
```
따라서 따옴표는 없지만 값이 아닌 유형을 반환합니다.

ConstraintResult 의 오버로드를 반환하는 것이 해결책인지 확신할 수 없었습니다.

일관성을 위해 PropertyConstraint가 하는 일을 고수해야 한다고 생각합니다. actual 값이 무엇인지에 대한 기본 표현을 표시하는 것은 실패한 것이 속성을 찾는 중이라는 메시지가 표시될 때 최악의 상황이 아닙니다.

ConstraintResult에서 파생된 새 클래스를 반환하는 것은 다른 제약 조건이 이를 사용자 정의하는 방법입니다.

좋아, 좋아 - 다음과 같이 들린다.
```c#
Assert.That(테스터, Has.Item(42d));

producers:

예상: 인수를 허용하는 기본 인덱서 < 42.0d >
하지만 다음과 같았습니다.
```

이는 속성 제약 조건 메시지와 일치합니다.

@nunit/framework-team 및 여러분, @Poimen 의 우수한 PR(https://github.com/nunit/nunit/pull/3609)이 다른 방식으로 병합될 준비가 되었기 때문에 이 질문에 대한 빠른 해결을 바랍니다.

내 관심을 끌게 @Dreamescaper 이 스레드에서 내 관심 높은까지 내가 추적을 잃었다 : 나는 두려워 사람들은 모두 기록됩니다 해요 읽기 Assert.That(collection, Has.Item("x")); 생각이 Has.Item 수단을 Contains.Item .
실패 메시지에 무언가를 추가하는 것을 고려할 수 있지만 소스 코드에서 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는 사용자의 관점에서 서로 어떻게 관련되거나 상호 작용하거나 비교할 것입니까?

[속성과 컬렉션 항목이 특정 수준의 추상화에서 동등하게 취급될 수 있다는 것을 알고 있지만 이것이 우리 대부분이 일반적으로 작동하는 추상화 수준은 아니라고 생각합니다. :smileing_imp: ]

NUnit 4.0의 경우 API에서 용어가 사용되는 방식을 살펴보고 약간 정리하는 것이 좋습니다. "멤버"라는 단어는 종종 "항목"과 동일하게 사용되지만 속성, 메서드 또는 변수를 의미할 수도 있습니다.

나는 부분적으로 Enumerable.ElementAt 위임하거나 동일한 특정 접근 방식을 취하는 것처럼 보일 수 있기 때문에 ItemAt over ElementAt 가장 편안합니다. ElementAt(int index) 에서 나를 강하게 놀라게 한 것은 작동 방식에 대한 세부 사항보다는 특히 index 라는 매개 변수와 관련된 BCL에 At 접미사에 대한 선례가 있다는 사실이었습니다 index .

이것을 ILookup과 함께 사용하는 경우 ILookup의 각 인덱스는 단일 요소/항목이 아니라 여러 TElement를 반환합니다. Has.EntryAt 는 컬렉션, 사전 및 인덱스당 다중 요소 조회와 함께 작동하는 것일 수 있습니다. 내 초기 반응은 Ilookup에서 IEnumerable<TElement> 를 반환하는 Has.ItemAt 가 충분히 이해할

다들 어떻게 생각하세요? 하나 이상의 작업이 작동하는 것을 볼 수 있으면 어렵지만 여기에서 대다수의 선호도는 사람들이 가장 쉽게 찾을 수 있는 이름을 나타내는 데 도움이 될 수 있습니다. @nunit/framework-team 이외의 사람들, 당신을 배제하려는 것은 아닙니다. 당신이 보고 있고 강한 느낌이 든다면, 그것은 항상 도움이 되는 데이터 포인트입니다!

@CharliePoole Has.Property("X") 는 인스턴스에 X 라는 매개변수화되지 않은 속성이 있다고 주장합니다. Has.ItemAt("X") 는 인스턴스에 문자열 매개변수를 허용할 수 있는 기본 인덱서(관련성이 없고 잘 알려진 이름을 가진 매개변수화된 속성)가 있다고 주장합니다.

Has.Property("X").EqualTo(3) 는 인스턴스에 매개변수화되지 않은 get 접근자를 호출하면 3 를 반환하는 X 라는 매개변수화되지 않은 속성이 인스턴스에 있다고 주장합니다. Has.ItemAt("X").EqualTo(3) 는 인스턴스에 특정 문자열 "X" 를 전달하면 3 를 반환하는 기본 인덱서(관련이 없고 잘 알려진 이름을 가진 매개변수화된 속성)가 인스턴스에 있다고 주장합니다. get 접근자.

기본 인덱서의 이름이 관련이 없는 이유는 C#, VB 및 F# 구문이 이름을 지정하지 않고도 기본 인덱서를 모두 호출할 수 있기 때문입니다. (따라서 '기본'이라는 용어) 기본 인덱서의 개념이 없지만 명명된 인덱서의 개념이 있는 언어는 이름을 지정해야 합니다. 기본 인덱서의 이름은 일반적으로 Item 이지만 기본 인덱서는 임의의 이름을 지정할 수 있으며 이러한 언어는 이름을 지정하지 않고 계속 호출할 수 있기 때문에 여전히 기본 인덱서가 될 수 있습니다. C#에서는 [IndexerName("ArbitraryName")] 특성을 사용하여 이 작업을 수행합니다.

@jnm2 실제로 인덱서에 대한 모든 C# 등의 언어를 이해하지만...

나는 재산 사이에 혼란의 가능성이 있다고 생각합니다.

• 실제 객체의 인덱서 __being__
• 인덱서가 있는 객체 __returning__
• 항목이 포함된 컬렉션 __반환__

나는 __you__이(가) 혼동하지 않을 것이며 아마도 당신과 이야기할 때만 가장하는 척 할 것이라고 강조하지만(socratic method, y' know :wink:) 하지만 많은 사람들이 그것을 혼란스럽게 생각할 수 있고 당신이 사람들에게 설명할 것이라고 생각합니다. 꽤 많이.

나는 추가에 반대하지 않지만 위의 구분은 문서에서 철자해야한다고 생각합니다.

추신: 전혀 소외감을 느끼지 않았습니다. :스마일리:

@CharliePoole 좋은 생각입니다. Has.ItemAt / Has.ElementAt / Has.EntryAt /etc 중에서 선택하는 데 영향을 미치지 않는 것처럼 들리므로 이름을 결정할 때까지 고려 사항을 표로 작성할 수 있습니까? 아니면 내가 놓친 부분이 있고 이 혼란 가능성을 기반으로 특정 명명 선택을 지원하고 있습니까?

지금까지 나는 ItemAt 쪽으로 기울고 있습니다. @Dreamescaper , 당신도 그 자리에 있습니까? @CharliePoole 당신이 ElementAt 대한 선호를 표현한 것인지 아니면 단지 우리가 프로세스를 통해 생각하도록 돕는 것인지 확신할 수 없었습니다.

Has.ItemAt / Has.ElementAt / Has.EntryAt /other에 더 많은 사람들이 참여할수록 사람들이 직관적으로 느낄 수 있는 것에 대해 더 많은 확신을 가질 수 있습니다. 우리가 그보다 훨씬 더 오래 걸리면 3.13 릴리스를 아주 소량으로 놓칠 것이기 때문에 다음 날 정도에 선두에 있는 것처럼 보이는 것을 그냥 부르고 싶습니다.

@jnm2 그냥 스스로 생각하고 격려하려고.

WRT 단어 선택, 내가 나열한 세 가지 유형의 표현과 어떤 특정 표현이 가장 잘 어울릴지, 그리고 걱정할 다른 조합이 있는지 궁금합니다. 내가 언급한 세 가지 옵션을 사용하면

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

그래서 나는 당신이 옳다고 생각합니다. 단어는 어떤 옵션에도 중요하지 않습니다.

장기적으로 볼 때 대괄호로 실제 인덱싱을 사용하는 것이 좋습니다. 그러나 클래스 집합으로 모델링하는 대신 실제로 제약 조건 표현식을 컴파일해야 합니다.

나는 이것이 내 급여 등급 이상이라는 것을 알고 있습니다.

나는 ItemAt 좋아합니다.

@CharliePoole이 제안한 대로 몇 가지 사용 사례를 생각하면서 시간을 보냈습니다. ElementAt 가 IEnumerable 상황에서 더 많이 사용되고 언어 인덱서가 IEnumerable 이상을 처리할 수 있다고 생각했습니다. 나는 잠시 동안 ElementAt 울타리에 앉아 있다가 다음과 같이 생각했습니다.
```c#
Assert.That(..., Has.ElementAt("하나", "둘"));

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(...)가 더 이상 자체 해결되지 않도록 pull 요청을 진행했으며 Has.Indexer 을 추적하기 위해 https://github.com/nunit/nunit/issues/3690 을 제출했습니다. Has.Indexer 를 사용하여 해당 기능을 제공합니다.