Google SoC 2016

Application Process

All participants should take a look at the Summer of Code student manual every now and then to be informed about updates and advices. It is also important to read the Summer of Code FAQ, as it contains useful information.

To apply, you need to come up with a project you are interested in. You can find some ideas listed below, but feel free to propose an entirely new idea. We encourage students who plan to apply to contact us about their interests and explain their project ideas as early as possible. The final application should be submitted through the GSoC webapp before the 25th of March.

The main requirement for working with EvoSuite is solid Java skills. Beyond that, the specific skills needed will mostly depend on which part of EvoSuite your project targets. Many core parts of EvoSuite depend on transformations and instrumentation of the Java bytecode, and therefore an understanding of Java bytecode would be helpful. The test generation is based on a genetic algorithm, and so search improvements will require an understanding of metaheuristic search algorithms.

The application consists of a project proposal in which you describe the project and why you are suitable to implement this project. There are many websites out there that provide hints on writing such proposals. Your proposal should include enough technical details, in particular:

  • What is the problem that you want to solve?
  • What are the benefits that solving this problem will bring to users of EvoSuite?
  • What are the components and dependencies of your solution?
  • Which parts can be omitted if development takes longer than you expect?
  • What is the timeline for design, development, and testing of the individual components?

In addition to the technical project description, include some information about yourself in the proposal:

  • Who are you, and what are you studying?
  • What is your native language?
  • Where do you live, and what time zone are you in?
  • What experience relevant to your proposal do you have?
  • Have you used EvoSuite?
  • Have you modified EvoSuite?
  • Why are you the right person to implement your proposal?
  • How many hours are you going to work on this project a week?
  • Do you have other commitments that we should know about?
  • What is your GitHub username?
  • How will you track your work?

Project Ideas

Please consider these ideas as starting points for generating proposals. We are also more than happy to receive proposals for other ideas related to EvoSuite.

Test Generation for Multithreaded Code

EvoSuite currently only works well for single-threaded code, and joins all threads that were spawned by the code under test after each test execution. It would be great if EvoSuite could specifically test classes that are intended to be concurrently accessed by several threads, as well as code that works and spawns several threads.

Test Generation for GUI classes (Swing/JavaFX)

EvoSuite currently runs in headless mode, which means that no GUI components are rendered, but this means that covering classes that depend on GUI components is difficult. A possible project could look at how to overcome this problem, for example by providing replacement classes (mocks) for the GUI components.

Bytecode Testability Transformation

EvoSuite uses a search-based approach to generate tests, and this search is guided by a fitness function that estimates how close a branch (e.g. true/false outcome of an if-condition) is to evaluating to true and to false. This works well on conditions that compare numbers, but when a condition just looks at a boolean value, then there is no guidance as the boolean can only either be true or false. To overcome this problem, testability transformation changes the program such that a boolean represents a numeric value of “how true” or “how false” it is, which can then guide the search. There has been a proof of concept showing that this can be done as a transformation of Java bytecode, and it would be very useful for EvoSuite to have a working approach to this transformation.

EvoSuite Gradle Plugin

EvoSuite has an existing plugin for integration in the Maven build infrastructure. However, Gradle is gaining momentum, and EvoSuite needs a Gradle plugin.

EvoSuite Eclipse Plugin

EvoSuite has an old experimental plugin for the Eclipse IDE, but this requires a rewrite to improve the user experience, and to allow proper integration into larger projects where multiple developers share the same codebase.

EvoSuite-as-a-Service

Similarly to how Travis integrates with GitHub repositories, a service could be provided that applies EvoSuite automatically for GitHub repositories and provides the resulting tests as pull-requests to the developers.

Plugin Infrastructure

EvoSuite has a huge number of properties, but many of the features are only needed in rare cases. The aim would be to provide a working plugin infrastructure to allow dynamic extension of EvoSuite;s functionality by loading additional plugins (e.g. to support other output formats such as TestNG or to use other search algorithms).

EvoSuite and JML/Design by Contract

EvoSuite generates regression tests that pass on the current version of the program. If there are contracts, for example specified using JML, EvoSuite could instead aim to exercise these contracts and report contract violations.