Fixes issue #1917

[sectorpre]

Fixes #1917 where Mockito cannot differentiate injection between classes with different type parameters. Instead of passing
constructor.getParameterTypes() to argResolver it passes constructor.getGenericParameterTypes() in order to properly compare the Type Parameters of the objects that are being injected. Also added tests to ensure Mockito is injecting mocks as intended and corrected tests that used the original resolveTypeInstances() vs the new resolveTypeInstancesGeneric()

Checklist

• Read the contributing guide
• PR should be motivated, i.e. what does it fix, why, and if relevant how
• If possible / relevant include an example in the description, that could help all readers
  including project members to get a better picture of the change
• Avoid other runtime dependencies
• Meaningful commit history ; intention is important please rebase your commit history so that each
  commit is meaningful and help the people that will explore a change in 2 years
• The pull request follows coding style
• Mention Fixes #<issue number> in the description if relevant
• At least one commit should mention Fixes #<issue number> if relevant

[Hemmels]

I love that I stumbled upon this issue today, and it was raised in April 2020 and someone has a fix for it 4 days ago.

I have a Test that fails with 4 Typed objects, but I was hoping Mockito would use the field names to inject the correct instances, given type erasure. I tried with @mock(name="myObjectOfStringType") and @mock(name="myObjectOfListType") etc Instead, it seems to randomly inject 1 of the mocks to all 4 objects in my class.
Using Mockito 5.5.0.

Would very much appreciate this fix going in.

[TimvdLippe]

You are removing the only usage of resolveTypeInstances afaik, so instead of introducing a new method, let's fix the existing method.

[TimvdLippe]

Do we really need this hashmap? You are comparing objects with strings in the hashmap in the implementation, but that can lead to false-positives. I am also not sure why we would do that lookup there, as we can also pass in all the fields of the testclass into the lookup and perform the injection there.

[sectorpre]

Hi thanks for the feedback! Definitely do agree that the hashmap is quite redundant but there's an issue storing mocks as a set of Objects, as this causes type erasure. I'll try to remove this hashmap in the next commit as well as store mocks as a set of Types instead of Objects.

[codecov-commenter]

Codecov Report

Attention: 24 lines in your changes are missing coverage. Please review.

Comparison is base (6f4eb02) 85.51% compared to head (261c26c) 12.41%.
Report is 11 commits behind head on main.

Additional details and impacted files

@@              Coverage Diff              @@
##               main    #3154       +/-   ##
=============================================
- Coverage     85.51%   12.41%   -73.11%     
+ Complexity     2908      424     -2484     
=============================================
  Files           333      333               
  Lines          8852     8879       +27     
  Branches       1095     1104        +9     
=============================================
- Hits           7570     1102     -6468     
- Misses          994     7566     +6572     
+ Partials        288      211       -77     

Files	Coverage Δ
...ito/internal/util/reflection/FieldInitializer.java	0.00% <0.00%> (-89.57%)	⬇️
.../configuration/injection/ConstructorInjection.java	2.50% <0.00%> (-97.50%)	⬇️

... and 302 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.