search

gintool / gin

GI in No Time - a Simple Microframework for Genetic Improvement
MIT License
43 stars 21 forks source link

Malformation in methods names - Profiling Problem (probably) #87

Closed GiovaniGuizzo closed 2 years ago

GiovaniGuizzo commented 2 years ago

The profiling is capturing some weird methods names, for example:

org.jgrapht.demo.WarnsdorffRuleKnightTourHeuristic.Integer>getMoveWarnsdorff(Pair<Integer,Integer>)

the .Integer> before the method name seems wrong and is causing a few problems with the GP execution. It does not find the method. The same occurs for some unit tests names: org.ognl.test.StaticsAndConstructorsTest.isOk(@org.ognl.test.objects.SimpleEnum@ONE

I don't know how to solve it.

GiovaniGuizzo commented 2 years ago

I discovered why it is getting Integer>getMoveWarnsdorff as the name of the method. The method signature is Pair<Integer, Integer>getMoveWarnsdorff and this code here removes the return type based on the first space split.

I think the return type can have spaces and it's messing with the parsing. I'll check the UnitTests too.

GiovaniGuizzo commented 2 years ago

I forgot the test units classes are still broken. I'll fix it later today.

GiovaniGuizzo commented 2 years ago

Ok, so I found out why Gin cannot parse the unit tests names correctly for some projects.

Take this project as an example: https://github.com/jkuhnert/ognl Its tests are defined at runtime like this. The tests are given a name, an expression, and an expected result. Notice the second string in each tuple. That's the name of the test case. It has spaces, special characters, numbers, etc.

Gin's code that deals with test cases' names checks for spaces and gets the first string as the name of the method. The check is done to remove parameters from the methods names. However, for projects like this one, the code generates wrong test case names.

I don't think there's an easy fix for this or that Gin can actually be compatible with test cases written in this style.

I'm closing this issue for now.

sandybrownlee commented 2 years ago

Agreed: the initial problem in this issue is fixed by 388d59a but this latter problem will need a lot more thought (if it's possible at all). It might be worth adding a note on this in the docs somewhere.