onewhl / kute Goto Github PK

Now, the heuristics works for JUnit5 only (looks at @ParameterizedTest annotation)
For JUnit 4, the following ways are possible:

• class with @RunWith(Parameterized.class) annotation
• with JUnitParams dependency: class has @RunWith(JUnitParamsRunner.class) annotation, methods have @Parameters(...) annotation
• with junit-dataprovider-core dependency: class has @RunWith(DataProviderRunner.class) annotation, methods have @UseDataProvider(...) annotation

For TestNG:

• methods annotated with @Parameters(...)
• methods annotated with @Test(dataProvider=...)

Currently, JSON content is printed in a large single line, which makes troubles on most text editors when opening result.json.
I suggest to separate entries by CRLF separator

Currently, we need id only for database. Let the database manage id itself

Experiment with different writer targets:

• JDBC with Database
• small files
• CSV
• JSON
• Parquet
• custom binary format

There are a few places where this util could be run, I suggest adding at least some JVM_OPTS to the Gradle file
If we have a GUI or web-interface, it will be great to have some settings there

Currently, we exclude tests with Disabled or Ignored annotation from analysis. Instead, let's add a feature disabled to TestMethodInfo

Frameworks to be supported: JUnit3, JUnit4, JUnit5, TestNG, kotlin.test

They may have platform-specific directories like jvmMain, jsTest, not just main and test.
Example: https://github.com/InsertKoinIO/koin/tree/main/core/koin-core/src

This uses , and ; (when you append newLine) to form csv output, but method body could contains ,;/n an so on.

I see a few possible solutions here

1. Strictly control the delimiters: it should be unique and never be used in the Java code as a symbol
2. Encode the body to the base64 or another String code which doesn't contain standard csv delimiters
3. Exclude the body collection

Old JUnit projects (pre-annotation time) used name convention to detect methods to be executed as test. It may be useful to support this heuristics beside annotation-based, so we could analyze historical projects

In some projects, tests are located in a separate module. Provide a way to map source class in the other module

Investigate the possibility to parse tests written in other languages

• Kotlin
• Groovy
• Scala

Support IO and computation parallelism

Now, we need to download project manually and unzip it (if it's loaded as a zip file)

Display name should be taken from the content of DisplayName annotation from JUnit5 or similar annotation from Allure framework

Currently, the CliktCommand implementation is used, and the run method contains all the main logic of parsing.

I suggest to move this logic to the separate Parser with the input arguments which could be filled from different client sources: web UI, desktop GUI, main function or the ClicktCommand implementation

There are a few versions to build a GUI:

1. SWING
2. JavaFX
3. Compose for Desktop
4. Some simple pure HTML pages run behind the KTor (probably could be set up on the ML Server)

Now we could not track the progress of test handling.

I suggest adding some logger calls with DEBUG level for the tracking what unit tests were discovered and visited, probably processed modules and some stats à la (100/11000 were processed)

JavaParser allows to bind only a single line comment to a method. Provide a way to collect siblings