Fixes GH2626 - removes the null-coalescing assignment operator when …

[clrudolphi]

…processing items in the Enumerable Value Retriever; which forces the EVR to find and use the most appropriate Value Retriever for each item in the list (instead of assuming that each item can be processed by the ValueRetriever found for the first item in the list).

Types of changes

• [X ] Bug fix (non-breaking change which fixes an issue).
• [ ] New feature (non-breaking change which adds functionality).
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
• [ ] Performance improvement
• [ ] Refactoring (so no functional change)
• [ ] Other (docs, build config, etc)

Checklist:

• [X ] I've added tests for my code. (most of the time mandatory)
• [ ] I have added an entry to the changelog. (mandatory)
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.

[bollhals]

Hmm this case is a bit unfortunate, but apart from the null value, is there any example where you'd want to retrieve the same type via 2 valueretrievers? It doesn't make sense to me. I have a ValueRetriever to handle a type, so if I have a enumerable of that type, I expect the one retriever to be able to handle it no?

I'm wondering if it wouldn't be better to extend the Null value handling in the StructValueRetriever , so you could set a value that is treated as null, like in the NullValueRetriever

[SabotageAndi]

@bollhals I found the example in the issue (https://github.com/SpecFlowOSS/SpecFlow/issues/2626) convincing me to accept this change. At the moment we guess the value retriever from the first row, which is not ideal and a surprising behavior for the user.