Request: Add support of indexers to the PropertyConstraint

[Ch0senOne]

At the moment it is only possible to test values of normal properties and no way to test indexer values. I need to write a test that looks something like this:

  [TestFixture]
  public class TestClass
  {
    class Example
    {
      private Dictionary<string, string> dictionary = new Dictionary<string, string>();

      public string this[string key]
      {
        get { return dictionary[key]; }
        set { dictionary[key] = value; }
      }
    }

    [Test]
    public void Test()
    {
      var obj = new Example
      {
        ["TEST1"] = "1",
        ["TEST2"] = "2",
      };

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

[jnm2]

I like the idea.

C# doesn't support named indexed properties but VB.NET does. I think the syntax .Property("Name", index1, ...) should be reserved for named indexers, so I wouldn't want to see that be used for a default indexer. I'd like to be able to respect the C# language by not requiring people to pass in a name parameter.

What do you think about Has.Item("TEST1").EqualTo("1") or Has.Index("TEST1").EqualTo("1")?

[Ch0senOne]

@jnm2
Having "Item" or "Indexer" method as a shortcut is convinient, but it is actually possible to change indexer name in C#: https://stackoverflow.com/questions/5110403/class-with-indexer-and-property-named-item

[jnm2]

@Ch0senOne It is possible to change the name. To be clearer I should have said, it is not possible to make a non-default indexer in C#. For example, you can't declare two indexers, nor can you consume the name from C#.
Thinking it over I'm afraid Has.Item("value") would be too confusable with Contains.Item. So maybe Has.Index("value")?

So I'd be in favor of Has.Index("IndexValue") for the default indexer and Has.Property("PropertyName", indexParams) for non-default indexers. Has.Property would end up working for default indexers too even though the idiomatic C# thing to do would be to use Has.Index.

---

Or if we wanted to be cute, we could do Has.Index["IndexValue"] and
Has.Property("PropertyName")[indexparams]... 😁

Actually, I wonder if we could get away with Has.Item["AtIndex"] using indexer syntax in order to avoid being confused with Contains.Item("ItemValue")... not sure what I think about that!

---

Let's see what the other @nunit/framework-team members think.

[CharliePoole]

We already defined a direction to go on properties using lambdas rather than strings. Seems like time might be better spent on that. I'm on my phone so I can't give you the issue number.

[jnm2]

@CharliePoole #26?

That makes sense for Has.Property. We could do:

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

I still think we should not do anything with Has.Property until non-default properties are needed, and for now just provide Has.Index(value1, ...) or Has.Index[value1, ...] or Has.Item[value1, ...] for the vastly more common default indexers.

[CharliePoole]

That's the one. I agree with you on named indexers, which haven't been requested anyway.

[crush83]

@jnm2 For your consideration, you can make a multi-keyed indexer as well. For example

this[string key1, string key2]

I'm wondering if there is any update on this issue, or current way of testing indexers on a type that doesn't inherit IEnumerable. I suppose I could just check for a KeyNotFoundException being thrown. Anything else I'm overlooking to allow me to check for the existence of a key in an indexer?

[jnm2]

@crush83 Yes, my index1, ... syntax was meant to indicate that we should consider them whatever we do.

I do not like the terminology key unless we are talking about an object that is actually a dictionary or keyed collection. Those are things with default indexers, but not all things with default indexers have keys. (Since you are using this terminology, maybe you'd find our Contains.Key syntax to be helpful? Can we improve it?)

There's been no progress other than what you see here. We need a proposal. To put something out there, my current favorite is Has.Item(params object[] indexerArgs) which would call the default indexer no matter what its name is.
Would this do everything requested so far?

[Thaina]

+1

[jnm2]

@nunit/framework-team Would you support the following new 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);
    }
}

I would probably leave the IndexerConstraint class internal until there's a reason to add it to the API.

[ChrisMaddock]

Sounds good to me.

Another vote in favour, I just wanted this feature for a console test. 🙂