ListMapper.Property doesn't work with fields

[Ian Appleby]

When using the ListMapper to perform a task such as:
> List.Map(values).Property("subValue")
the expected outcome (a list of subValues) is achieved if the property subValue is encapsulated (get/set), but not if it's a field.

I'd assume this is a reflection quirk, but I'm not up on the details.

[Ian Appleby (ian-appleby)]

Sorry didn't include:
present in nunit-2.6 (release) running on .NET framework 4.0

[Charlie Poole (charlie.poole)]

As stated in the docs, "Currently, ListMapper supports one transformation: creating a collection of property values. "

It's certainly possible to add a feature that accesses fields in 3.0 although it's possible that the whole thing will be replaced with the use of lambdas.

We'll use this bug as a placeholder for the issue, however it turns out.

[Ian Appleby (ian-appleby)]

One way or the other I vote it should be included.

The original .NET design plan for Property was to allow it to transparently replace a field, so that you didn't have to use superfluous getters/setters from the outset, but instead could add them as required without refactoring other classes. It's always been a plus point for me, and I'd like to see the same principle carried through testing.

[Charlie Poole (charlie.poole)]

We have other places in the NUnit syntax where we accept equally Properties, Fields and Methods. We just don't use the word 'Property' to describe them. Perhaps that's the way to handle this. Once we are using the word 'Property' we are conceptually at a level of implementation, below the point where fields and properties are interchangeable.

In fact, I think it would be desireable to get rid of the need to specify strings as names entirely, which is why I lean more toward the use of Lambdas in the future.