Extract utbot-spring-framework module from utbot-framework #2570
Conversation
IlyaMuravjov added ctg-refactoring IlyaMuravjov force-pushed the ilya_m/spring-module branch from ef70874 to ec3beff Compare …ecific Remove `CgContext.relevantFieldManagers` field
… to `utbot-spring-test`
Remove duplicated `include("utbot-spring-framework")` in `settings.gradle.kts` …ementing `CodeGenerationSettingItem` as it's not a setting
IlyaMuravjov force-pushed the ilya_m/spring-module branch from ec3beff to 4b95114 Compare 
Damtev left a comment
Damtev left a comment There was a problem hiding this comment.
There are some unobvious moments
| watchdog.measureTimeForActiveCall(perform, "Performing dynamic task") { params -> | ||
| val task = kryoHelper.readObject<EngineProcessTask<Any?>>(params.engineProcessTask) | ||
| val result = task.perform(kryoHelper) | ||
| kryoHelper.writeObject(result) | ||
| } |
There was a problem hiding this comment.
Why do we have only one post-processing task? Perhaps it could be a list of such tasks performed consequently.
There was a problem hiding this comment.
- It's not a post-processing task, the order in witch callbacks are registered in the engine process has nothing to do with the order in which they are called by the IDE process. For example, callback for
findMethodsInClassMatchingSelectedis registered after the callback forgenerate, despitegeneratebeing called afterfindMethodsInClassMatchingSelected. - If we need to perform multiple tasks we can call
performmultiple times, the same waygenerateis called multiple times when we generate tests for multiple classes.
| @@ -0,0 +1,39 @@ | |||
| val kotlinLoggingVersion: String by rootProject | |||
| val rdVersion: String by rootProject | |||
| val sootVersion: String by rootProject | |||
There was a problem hiding this comment.
Do we really need Soot for this module?
There was a problem hiding this comment.
Right now NonNullSpeculator accepts SootField.
I've tried making engine convert SootField to FieldId before passing it to speculativelyCannotProduceNullPointerException, but it was failing to convert declaring SootClass to a valid ClassId for some lambdas, causing ClassNotFoundException when the default implementation of the speculativelyCannotProduceNullPointerException tried to retrieve the packageName which in turned used jClass.
| @@ -0,0 +1,27 @@ | |||
| package org.utbot.framework.codegen.domain | |||
| | |||
| abstract class SpringModule( | |||
There was a problem hiding this comment.
Made it a enum.
| import org.utbot.rd.use | ||
| import org.utbot.spring.process.SpringAnalyzerProcess | ||
| | ||
| class SpringAnalyzerTask( |
There was a problem hiding this comment.
Is it true that it does not matter will this task be performed before the symbolic analysis or after? So, can we always consider it as a post-processing task?
There was a problem hiding this comment.
It's always performed before symbolic analysis and its results are later used to guide type replacement during symbolic execution.
| object RelevantFieldManagersProperty : CgContextProperty<MutableList<CgAbstractClassFieldManager>> | ||
| | ||
| /** | ||
| * Managers to process annotated fields of the class under test | ||
| * relevant for the current generation type. | ||
| */ | ||
| val CgContextOwner.relevantFieldManagers: MutableList<CgAbstractClassFieldManager> | ||
| get() = properties.getOrPut(RelevantFieldManagersProperty) { mutableListOf() } | ||
| |
There was a problem hiding this comment.
It's not very obvious why this object and this extension method (which seem to be common for any possible extension to the CgContext - Spring, or any other in the future) are located in this Spring-specific module
There was a problem hiding this comment.
I agree, there's nothing Spring-specific in declaring class fields. However, right now adding FieldManagers won't have any effect unless CgSpringVariableConstructor is used. I've been always in favor of separating Spring-specific and field-declaration-specific logic into 2 decorators of VariableConstructor instead of one inheritor made an issue regarding that, see #2579.
| val springAnalyzerResult = structdef { | ||
| field("beanDefinitions", array(beanDefinitionData)) | ||
| val performParams = structdef { | ||
| field("engineProcessTask", array(PredefinedType.byte)) |
There was a problem hiding this comment.
Based on its usage, this task seems to always be post-processing. Am I right? If so, please rename it correspondingly
There was a problem hiding this comment.
No, see reply to the first comment.
Description
All spring-specific logic is extracted from
utbot-frameworkmodule toutbot-spring-frameworkmodule.How to test
Regression tests, this PR should not change UtBot semantics at all.
Self-check list