Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fill SortedDictionary #623

Closed
ploeh opened this issue May 18, 2016 · 7 comments · Fixed by #669
Closed

Fill SortedDictionary #623

ploeh opened this issue May 18, 2016 · 7 comments · Fixed by #669

Comments

@ploeh
Copy link
Member

ploeh commented May 18, 2016

When you ask AutoFixture for a dictionary, it provides a non-empty value:

var fixture = new Fixture();
var actual = fixture.Create<IDictionary<int, string>>();
Assert.NotEmpty(actual); // Succeeds

When you request a sorted dictionary, on the other hand, the returned collection is empty. This test fails its assertion:

var fixture = new Fixture();
var actual = fixture.Create<SortedDictionary<int, string>>();
Assert.NotEmpty(actual); // Fails

Since AutoFixture can already supply non-empty dictionaries, and one of the constructor overloads for SortedDictionary<TKey, TValue> takes a dictionary, it ought to be fairly easy to add a relay from SortedDictionary<TKey, TValue> to IDictionary<TKey, TValue>.

The implementation could for example be a new ISpecimenBuilder that handles requests for any SortedDictionary<TKey, TValue> by resolving IDictionary<TKey, TValue> from the context, and then invoking the appropriate constructor overload with the returned value.

Another implementation option is to mimic the way concrete dictionaries are already filled. See the combination of DictionaryFiller and DictionarySpecification in the Fixture class.

@ploeh
Copy link
Member Author

ploeh commented May 18, 2016

See also #622 and #624.

@rahulpnath
Copy link
Contributor

@ploeh Do you have any thoughts on how to support custom comparer for the SortedDictionary Key.

I just started on with this. It works fine for types that have a default comparer, but fails for complex types, objects etc. Would going down creating a custom request object with the comparer as a property be the right path.

@ploeh
Copy link
Member Author

ploeh commented Jun 30, 2016

Could the feature be implemented similar to ##629? Since that implementation chose the Specification options, I'd prefer it if this and #622 use the same approach, if at all possible.

@rahulpnath
Copy link
Contributor

rahulpnath commented Jul 5, 2016

@ploeh Cool will use the Specification approach. But even with the sorted set specification approach, I don't see how this would work?

var result = fixture.Create<SortedSet<object>>();

It fails with below error (as expected)
Test 'Ploeh.AutoFixtureUnitTest.FixtureTest.CreateSortedSetReturnsCorrectResult' failed: System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
---- System.InvalidOperationException : Failed to compare two elements in the array.
-------- System.ArgumentException : At least one object must implement IComparable.

Is that the expected behavior?

@ploeh
Copy link
Member Author

ploeh commented Jul 5, 2016

What is it creating?

@rahulpnath
Copy link
Contributor

rahulpnath commented Jul 5, 2016

@ploeh Sorry that got trimmed in markdown formatting

Updated it SortedSet of object or any type that does not have a default comparer

@ploeh
Copy link
Member Author

ploeh commented Jul 5, 2016

Is the situation different from when one requests IDictionary<TKey, TValue>?

@ploeh ploeh closed this as completed in #669 Jul 5, 2016
ploeh added a commit that referenced this issue Jul 5, 2016
in order to indicate that auto-population of SortedDictionary<,> is a new
feature. This resolves #623
(#623).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants