Introduce Spring integration tests

[IlyaMuravjov]

Description

Introduce Spring integration tests that start SpringApplication and autowire tested class instance.

How to test

Manual tests

Generate tests for spring-boot-testing-main after putting the following in the application.yml.

spring:
  datasource:
    url: jdbc:h2:mem:testdb
    username: sa
    password: password
  jpa:
    hibernate:
      ddl-auto: create-drop
    show-sql: true
    generate-ddl: true

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.

[sergeypospelov]

utbot-instrumentation lgtm

[Markoutte]

Inversion of dependencies between classes. FuzzedType should know nothing about how it is used.

[IlyaMuravjov]

Maybe something like hasCustomCreationMechanism could be a better name. The alternative is to make ObjectValueProvider aware of AutowiredFuzzed, but it seems more wrong to me.

[Markoutte]

The better way I see is to use marker interface to implement, like:

interface CustomValueProvider {
    fun getProvider(): ValueProvider
}

FuzzerType itself shouldn't implement that interface, but AutowiredFuzzerType should.

[IlyaMuravjov]

Great idea, but I think this interface should be called CustomJavaValueProviderHolder with val property instead of the getter. In case of AutowiredFuzzedType, javaValueProvider can be injected into it via constructor by SpringFuzzedTypeFactory so we avoid cyclic dependency between AutowiredFuzzedType and AutowiredValueProvider.

Finally, we can add DelegatingToCustomJavaValueProvider to defaultValueProviders.

interface CustomJavaValueProviderHolder {
    val javaValueProvider: JavaValueProvider
}

object DelegatingToCustomJavaValueProvider {
    fun accept(type: FuzzedType): Boolean = type is CustomJavaValueProviderHolder

    fun generate(description: FuzzedDescription, type: FuzzedType): Sequence<Seed<FuzzedType, FuzzedValue>> =
        (type as CustomJavaValueProviderHolder).javaValueProvider.generate(description, type)
}

There's nothing Java specific about the code above, but if we use generic ValueProviderHolder<T, R, D : Description<T>> and DelegatingToCustomValueProvider<T, R, D : Description<T>> then unsafe cast to ValueProviderHolder<T, R, D> is needed instead of cast to CustomJavaValueProviderHolder.

[Markoutte]

Look likes a workaround for a particular problem. Please, consider making it in more a general way. Also, the cache is used to keep types correctly, but know it is possible to make infinite recursive definition. Please, check that example like this method works correctly in test for the type resolving.

[IlyaMuravjov]

We can accept an instance of FuzzedTypeFactory:

interface FuzzedTypeFactory {
    fun createFuzzedType(type: Type, isThisInstance: Boolean)
}

It will have two implementations:

• PureJvmFuzzedTypeFactory traverses types recursively and incapsulates everything cache-related
• SpringFuzzedTypeFactory is a decorator that makes this instance type to be autowired

[Markoutte]

I think it is good idea to use factory with decorators in this case 👍

[Markoutte]

Looks like it is time to write here smth like this:

val rdGenerateResult = process.generate(
    conflictTriggers = model.conflictTriggers,
    methods = methods,
    mockStrategyApi = model.mockStrategy,
    chosenClassesToMockAlways = model.chosenClassesToMockAlways,
    timeout = model.timeout,
    generationTimeout = model.timeout,
    isSymbolicEngineEnabled = false,
    isFuzzingEnabled = true,
    fuzzingValue = project.service<Settings>().fuzzingValue,
    searchDirectory = searchDirectory.pathString
)

[Markoutte]

As we discussed with @EgorkaKulikov we can rebase it into the main, because it doesn't break general fuzzing, but we still need to refactor the Spring part in fuzzing module with @IlyaMuravjov to improve some concepts.