Heuristics for variable naming

[GeraldineGalindo]

Hi! This small PR proposes a new mode of using methods and arguments information (obtained via reflection) for naming variables in EvoSuite-generated tests.

Currently, the variable naming is based on the variable type with an index number indicating the number of repetitions the name presents. To improve readability this change proposes using little heuristics on the TestCodeVisitor class to gather code information and rename variables. Consider the following examples of test3, The first one uses linkedList0 and linkedList1 for naming two variables sent as arguments of the BookStore class.

  public void test3()  throws Throwable  {
      LinkedList<Book> linkedList0 = new LinkedList<Book>();
      LinkedList<Author> linkedList1 = new LinkedList<Author>();
      BookStore bookStore0 = new BookStore(linkedList0, linkedList1);
     ...
  }

In this case, we propose to use information about the names of the arguments in the BookStore declaration to give more meaningful names (related to the class under test) as seen in the following version of test3:

public void test3()  throws Throwable  {
      LinkedList<Book> books = new LinkedList<Book>();
      LinkedList<Author> authors = new LinkedList<Author>();
      BookStore bookStore = new BookStore(books, authors);
     ...
  }

Our little heuristics implemented in this PR include using method argument names, and method names (+ a little modification on the first words of the suggested name). Please let us know your thoughts/suggestions about it!

To test the additions in this PR, change the attribute VariableNamingStrategy in the Properties class to:

@Parameter(key = "variable_naming_strategy", group = "Output", description = "What strategy to use to name variables for tests")
public static VariableNamingStrategy VARIABLE_NAMING_STRATEGY = VariableNamingStrategy.HEURISTICS_BASED;

Then, compile to obtain the jar file. For generating tests, you must compile the project under test with the option -parameters configured for javac, this is used to obtain the methods argument names by reflection. You can configure this option in your IDE (Settings > Build, Execution, Deployment > Compiler> Java Compiler > Additional compile line parameters) in IntelliJ)or the pom.xml file in Maven.

[jose]

We might need to discuss the pros/cons of pull requests #451 and #441 before going ahead. @GeraldineGalindo any chance you could summarise the pros/cons of this pull request vs. #441?

[GeraldineGalindo]

We might need to discuss the pros/cons of pull requests #451 and #441 before going ahead. @GeraldineGalindo any chance you could summarise the pros/cons of this pull request vs. #441?

Thanks for the comment! Sure:

As I reviewed, #441 proposes a good structure for managing the responsibilities in the TestCodeVisitor class. The use of a strategy pattern opens more possibilities, heuristics proposed in #451 can be implemented with this structure, for less coupling.

I think that the main difference between both PRs is the focus of each one, as I understand #441 proposes the base structure for using different naming strategies. In contrast, #451 proposes two heuristics besides the type-based one using information gathered in visiting phase (which is why this PR introduces changes to the TestCodeVisitor class), therefore, I do not think that the PRs are comparable, instead, they can be complementary.

If more strategies could be crafted for variable naming in EvoSuite, a structure defined in #441 is needed to avoid the TestCodeVisitor class becoming a large class. However, this is designed to only use the information of the variable types obtained from the VariableReference class. #451 uses dictionaries for gathering and crafting variable names based on reflection information retrieval (so, adapting #451 to the structure in #441 would need some changes). If possible, I'd like to make a new PR adapting the heuristics proposed with the strategy pattern structure. What do you think about this option?

[GeraldineGalindo]

@jose, thanks again for the comments, we reviewed PR #441 again and did a little test to implement our naming suggestion with the proposed structure successfully. So, we kindly inquire about the status of #441, and if its refactoring would be included in EvoSuite, we'd like to upload a PR with the implementation using this new structure, and if it helps we'd be glad to meet and discuss the PR. Many thanks for considering my request.

[jose]

Thanks @GeraldineGalindo for your feedback. I'm going to merge #441. It would be great if could adapt/update #451 to use the new structure proposed in #441.

[GeraldineGalindo]

Thanks @jose for the response! I'm uploading the update of this commit to the new structure, and I'll be looking for comments or reviews on the proposal.

[jose]

Thanks @GeraldineGalindo.

[GeraldineGalindo]

Thanks @jose for reviewing and for your time :)