COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest
The `getMap()` method, when testing a `HashSetValuedHashMap`, would return an object of this type. Which is an instance of `SetValuedMap`.
Running it in debug mode would - most of the times - run the tests and succeed. Running normally - especially on Windows - would result in intermittent, but very frequent, failures.
The `getMap()` method sometimes, depending on the order and execution of tests, will be null. So the collection added to the map will be either a `Hashset`, or a `Arrays$ArrayList`. When the types are different, `hashCode()` and `equals()` calls return incorrect values, resulting in the errors we have seen in COLLECTIONS-661.
A good solution would be to re-design the tests. The `TestMultiValuedMapAsMap` is testing `MultiValuedMap`'s, which include `HashSetValuedHashMap`. However, some of its methods contain extra logic for when the type under test has some characteristics like being an instance of `SetValuedMap`.
It might be possible to come up with a better design, where there are multiple test classes, for `MultiValuedMap`'s that use `SetValuedMap`'s; `MultieValuedMap`'s that use `List`'s, and so it goes.
Or we could add a class to the parent class, with a flag defining the type under test. For now, I have used the `makeObject()` method, which returns the collection under test. Then I validate its instance type. There is also a comment above the code to indicate why we are using `makeObject()` and not `getMap()`.
It was a fun ticket. Happy to get feedback on better solutions, or feel free to edit this pull request if you have right to it, or merge if you are happy and it has gathered some consensus.
You can merge this pull request into a Git repository by running: