Improve mock type inference in fuzzer

[IlyaMuravjov]

Description

Substitute actual types from receiver type in place of type variables in mocks created by MockValueProvider.

For example, if stringOptional has type Optional<String>, then stringOptional.get() return value of type String.

How to test

Manual tests

1. Generate unit tests for OwnerService.getOrderById() method from spring-boot-testing project. There should be test like the one bellow and no tests for ClassCastException.

@Test @DisplayName("getOrderById: id = -9223372036854775807 (mutated from positive)") public void testGetOrderById() throws Throwable { Optional optionalMock1 = mock(Optional.class); Order orderMock1 = mock(Order.class); (when(optionalMock1.orElseThrow(any()))).thenReturn(orderMock1); (when(orderRepositoryMock.findById(any()))).thenReturn(optionalMock1); Order actual = simpleOrderService.getOrderById(-9223372036854775807L); assertSame(orderMock1, actual); Long actualId = ((Long) getFieldValue(actual, "com.rest.order.models.Order", "id")); assertNull(actualId); String actualBuyer = ((String) getFieldValue(actual, "com.rest.order.models.Order", "buyer")); assertNull(actualBuyer); Double actualPrice = ((Double) getFieldValue(actual, "com.rest.order.models.Order", "price")); assertNull(actualPrice); int orderMock1Qty = ((Integer) getFieldValue(orderMock1, "com.rest.order.models.Order", "qty")); int actualQty = ((Integer) getFieldValue(actual, "com.rest.order.models.Order", "qty")); assertEquals(orderMock1Qty, actualQty); }

2. Generate tests for methods that work with more complex receiver generic types, types should still be inferred correctly. Here's an example of such method:

public String getFirst(Optional<? extends List<? extends String>> optional) { return optional.get().get(0); }

Limitations

Generics are only inferred when they are declared at the class level, meaning that for methods that are themselves parametrized (e.g. <R> Stream<R> map(Function<? super T, ? extends R> mapper)) types are not inferred.

Self-check list

• I've set the proper labels for my PR (at least, for category and component).
• PR title and description are clear and intelligible.
• I've added enough comments to my code, particularly in hard-to-understand areas.
• The functionality I've repaired, changed or added is covered with automated tests.
• Manual tests have been provided optionally.
• The documentation for the functionality I've been working on is up-to-date.