TestSpark - a plugin for generating unit tests. TestSpark natively integrates different AI-based test generation tools and techniques in the IDE. Started by SERG TU Delft. Currently under implementation by JetBrains Research (ICTL) for research purposes.
MIT License
35
stars
9
forks
source link
enum class ClassType + FunctionType should be wrapped inside helpers/psi #240
Recently you implemented the following interface in the core
/**
* Enumeration representing different types of classes.
*
* @param representation The string representation of the class type.
*/
enum class ClassType(val representation: String) {
INTERFACE("interface"),
ABSTRACT_CLASS("abstract class"),
CLASS("class"),
}
Language specific
Firstly, this is Java specific (we have the same types in Kotlin, as well, but it will not be the case). For example, there are no ABSTRACT_CLASS in Python and even an interface is actually just a convention; in Kotlin we also have data class.
Therefore I would rethink this design. We can make an interface for this and an implementation per language. Or Just hide this enum inside the JavaImplementation.
Consistency violation
There are 2 functions that are doing more ore less the same thing. But implemented differently. I would suggest to stick to the same solution for getMethodDisplayName, as well. Namely, implement FunctionType / MethodType. and do this with the expectation that the functions are also language-specific. For example, Kotlin has function extensions;
override fun getClassDisplayName(psiClass: PsiClassWrapper): String =
(psiClass as JavaPsiClassWrapper).getClassDisplayName()
override fun getMethodDisplayName(psiMethod: PsiMethodWrapper): String {
return if ((psiMethod as JavaPsiMethodWrapper).isDefaultConstructor) {
"<html><b><font color='orange'>default constructor</font></b></html>"
} else if (psiMethod.isConstructor) {
"<html><b><font color='orange'>constructor</font></b></html>"
} else if (psiMethod.isMethodDefault) {
"<html><b><font color='orange'>default method</font> ${psiMethod.name}</b></html>"
} else {
"<html><b><font color='orange'>method</font> ${psiMethod.name}</b></html>"
}
}
PS
I am sorry that I bring this up after merging the PR.
Recently you implemented the following interface in the core
Language specific
Firstly, this is Java specific (we have the same types in Kotlin, as well, but it will not be the case). For example, there are no ABSTRACT_CLASS in Python and even an interface is actually just a convention; in Kotlin we also have
data class
.Therefore I would rethink this design. We can make an interface for this and an implementation per language. Or Just hide this enum inside the JavaImplementation.
Consistency violation
There are 2 functions that are doing more ore less the same thing. But implemented differently. I would suggest to stick to the same solution for
getMethodDisplayName
, as well. Namely, implementFunctionType
/MethodType
. and do this with the expectation that the functions are also language-specific. For example, Kotlin has function extensions;PS
I am sorry that I bring this up after merging the PR.