Summaries for tests generated by fuzzer are generated in the summary module #597

[amandelpie]

Description

1. Moved NameSuggesting API to summaries module
2. Shifted the stage of setting names/display names for fuzzing later, to the Summarization stage

Fixes #597

Type of Change

• Refactoring (typos and non-functional changes)

How Has This Been Tested?

Automated Testing

TODO: add unit-tests for fuzzing tests and its names too

Checklist (remove irrelevant options):

This is the author self-check list

• The change followed the style guidelines of the UTBot project
• Self-review of the code is passed
• The change contains enough commentaries, particularly in hard-to-understand areas
• New documentation is provided or existed one is altered
• No new warnings
• New tests have been added
• All tests pass locally with my changes

[amandelpie]

@Markoutte there is an open question how to pass information required to the Name generation outside the Fuzzer module.

I used UtExecution for that (adding two fields with types from Fuzzing module), but faced with some issues

1. class UtExecution is defined in Api.kt in utbot-framework-api and this module doesn't import fuzzer module (I don't know could I import it here?)
2. I could not inherit UtExecution (make FuzzingUtExecution and place it in utbot-framework or somewhere else) because it's a data class (the inheritance of data classes if forbidden in Kotlin). Could we convert it to usual class?

So I decided to keep something with types Any and fill these fields with specific types later in Java 4 style. I don't see huge objection not to follow this way

in my humble opinion, probably we need to extend the UtExecution hierarchy and make two sub-classes of the parent abstract class at this moment but it could be done in the following PR (it's not the goal of this PR)

[Markoutte]

I think we can do this trick like that: move the knowledge about data origin into the API or even another high-level module and unbind it from the fuzzer. I wouldn't move the knowledge about fuzzing (or any another possible way we generate names) to the summaries. But we can make a contract with a flex hierarchy of classes somewhere upper in module hierarchy (for example, one for those which have jimple body or which provide some internal knowledge about data origin).

I think, maybe, it is good idea to have something like "summary-api" or a package in framework-api for summaries. It gives us a way to choose how to fill this data for that summary. No summaries at all if we don't fill any.

Moreover it helps to merge the last 4 fields of UtExecution (createdBy, summary, testMethodName, displayName) into one object to pass further.

What do you think?

[amandelpie]

@Markoutte I'd like your proposal, and ready to try to implement this approach.

But I have an alternative suggestion: I have some tickets related to javadoc generation and clusterization for fuzzing and want to progress with them in parallel.

Could we merge this as it's implemented and start with depending tickets and in parallel start the discussion with team about changes in API?

[amandelpie]

@Markoutte @denis-fokin please have a look, I've implemented the proposed hierarchy of classes and handle separately each case where Symbolic Execution and Fuzzed Execution have different flows.

Also, I checked this manually, fuzzing and symbolic works well together

[Markoutte]

Fuzzing part and UtExecution looks good to me

[amandelpie]

@Damtev thanks for review, I solved the majority of the questions @EgorkaKulikov please have a look

[Damtev]

Minor: return if