Code Monkey home page Code Monkey logo

testgenie's Introduction

TestGenie

Build Version Downloads

Description

TestGenie is an external graphical IntelliJ plugin that integrates EvoSuite into the IDE. EvoSuite is a tool that automatically generates test cases with assertions for classes written in Java code. TestGenie makes this much easier, as it provides an intuitive modern interface for EvoSuite – so, no more CLI.

❗ DISCLAIMER ❗

Please keep in mind that tests generated by TestGenie are meant to augment your existing test suites. They are not meant to replace writing tests manually.

Features

Generating Tests for Classes

TestGenie uses EvoSuite to automatically generate tests for Java classes. Two clicks are required from the user for the tests to be generated.

Generating Tests for Methods

TestGenie uses EvoSuite to automatically generate tests for Java methods. Two clicks are required from the user for the tests to be generated.

Generating Tests for Lines

TestGenie uses EvoSuite to automatically generate tests for Java code lines. Two clicks are required from the user for the tests to be generated.

Coverage Table

Basic statistics for the test suite in form of a table.

Coverage Visualisation

TestGenie offers an option to highlight lines which the generated test suite covers. Clicking the gutter icon (green rectangle) to the left of the lines allows the user to see which tests cover the line. Clicking a name of a test highlights the according test in the "Generated Tests" tab to make it easy to spot.

Killed Mutants Visualisation

TestGenie offers an option to see which mutants were killed and by which tests. Clicking the gutter icon (green rectangle) to the left of the lines allows the user to see which tests cover the line. Clicking a name of a mutant highlights all the tests in the "Generated Tests" tab which cover it.

Caching Tests

Due to its nature, generating tests with EvoSuite takes time. TestGenie takes steps to address this as much as technically feasible by caching all generated test cases that the user has decided not to apply immediately. This then allows TestGenie to instantly show those tests later, when the user decides to generate tests for a method or class that those unapplied tests also covered.

Test validation

To assure that the cached tests are still valid, we have static and dynamic validation which are run before showing any cached tests.

Accessibility Features

Features which make the plugin more user-friendly. For instance, a color picker for coverage visualisation.

Telemetry (opt-in)

Opt-in non-intrusive data collection to improve EvoSuite in the future.

Installation

  • Using IDE built-in plugin system:

    Settings/Preferences > Plugins > Marketplace > Search for "TestGenie" > Install Plugin

  • Manually:

    Download the latest release and install it manually using Settings/Preferences > Plugins > ⚙️ > Install plugin from disk...

Usage

Important note before generating tests

If you are running the plugin for the first time, checkout the First time configuration section.

Generating Tests for Classes

To generate a test for a class, right-click (with mouse) anywhere within the class you want to test or right-click the class name itself (note that when using multiple cursors only the last one will count). Under the "TestGenie" option, select "Generate Tests for Class [...]" option:
Test generation for classes
EvoSuite going to run in the background and generate tests. While EvoSuite is running, a progress bar in the bottom right-hand corner of the IDE:
Progress bar
Once the tests are generated, they can be accessed in the "TestGenie" tool window (under "Generated Tests" tab), accessible via the stripe button on the right-hand side of the IDE:
Generated Tests
You can examine the created tests, select those you wish to be added to your test class (via checkboxes). The tests can also be edited inside their mini-editors. Hitting the "Apply to test suite" button will add the selected tests to a test class of your choice.
Additionally, the top row of the tool window has buttons for selecting all tests, deselecting all tests, removing (deleting) all tests, and validating them.. The user also has an overview of how many tests they currently have selected.
Quick buttons

Generating Tests for Methods

To generate a test for a method, right-click (with mouse) anywhere within the method you want to test or right-click the method name itself (note that when using multiple cursors only the last one will count). Under the "TestGenie" option, select "Generate Tests for Method [...]" option:
Test generation for methods
EvoSuite going to run in the background and generate tests. While EvoSuite is running, a progress bar in the bottom right-hand corner of the IDE:
Progress bar
Once the tests are generated, they can be accessed in the "TestGenie" tool window (under "Generated Tests" tab), accessible via the stripe button on the righthand-side of the IDE:
Generated Tests
You can examine the created tests, select those you wish to be added to your test class (via checkboxes). The tests can also be edited inside their mini-editors. Hitting the "Apply to test suite" button will add the selected tests to a test class of your choice.
Additionally, the top row of the tool window has buttons for selecting all tests, deselecting all tests, removing (deleting) all tests, and validating them.. The user also has an overview of how many tests they currently have selected.
Quick buttons

Generating Tests for Lines

To generate a test for a method, right-click (with mouse) anywhere within the line you want. Note that the line has to contain a statement (e.g. you will not have the option on lines with only method declarations). Under the "TestGenie" option, select "Generate Tests for Line [...]" option:
Test generation for methods
EvoSuite going to run in the background and generate tests. While EvoSuite is running, a progress bar in the bottom right-hand corner of the IDE:
Progress bar
Once the tests are generated, they can be accessed in the "TestGenie" tool window (under "Generated Tests" tab), accessible via the stripe button on the righthand-side of the IDE:
Generated Tests
You can examine the created tests, select those you wish to be added to your test class (via checkboxes). The tests can also be edited inside their mini-editors. Hitting the "Apply to test suite" button will add the selected tests to a test class of your choice.
Additionally, the top row of the tool window has buttons for selecting all tests, deselecting all tests, removing (deleting) all tests, and validating them.. The user also has an overview of how many tests they currently have selected.
Quick buttons

Coverage Table

Once a test suite is generated, basic statistics about it can be seen in the tool window, coverage tab. The statistics include line coverage, branch coverage, weak mutation coverage. The table adjusts dynamically - it only calculates the statistics for the selected tests in the test suite.
Progress bar

Coverage Visualisation

For coverage visualisation to work, you must have it turned on. The setting is available in the Quick Access tab. Coverage Visualisation Checkbox
Once test are generated, the lines which are covered by the tests will be highlighted (default color: green). The gutter next to the lines will have a green rectangle as well. If the rectangle is clicked, a popup will show the names of the tests which cover the selected line. If any of the test names are clicked, the corresponding test in the toolwindow will be highlighted with the same accent color. The effect lasts 10 seconds. Coverage visualisation adjusts dynamically - it only shows results for the tests that are selected in the TestGenie tab.
Test Highlight
For reference, without visualisation the window would look like this:
No Test Highlight

Killed Mutants Visualisation

For mutation visualisation to work, you must have coverage visualisation enabled. You must also have the criterion Mutation coverage turned on. The setting is available in the Settings > Tools > TestGenie > EvoSuite tab.
Turn on Mutation
Once tests are generated, the same gutter from Coverage Visualisation can be used to show which mutants are covered by the current test suite and which ones are not. For mutants covered, the mutant can be clicked. Clicking the mutant will highlight all the tests that kill the mutant. Mutation visualisation adjusts dynamically - it only shows results for the tests that are selected in the TestGenie tab.
Mutation Coverage

Caching Tests

When a user initially generates tests for a class, this will take some time, as the EvoSuite backend needs to be invoked. Then, if a user generates tests for a single method in this class, Test-Genie will look in its cache and find the tests that were previously generated for the entire class, and will instantly display them to the user rather than invoking EvoSuite again.
Before displaying cached tests, they are (in)validated statically and dynamically.
Cached Tests for Method

Test validation

Tests which are no longer representative of the current state of the code under test are dropped from the cache, as they are no longer valid. We have 2 types of cache validation - static and dynamic validation. Static validation removes tests from cache by analysing the structure of the methods inside a class. If a method is modified, the tests covering it would be invalidated. Furthermore, it ignores whitespace changes, formatting inside a method and also reordering methods inside a class. Dynamic invalidation comes after static invalidation and verifies that all tests in the cache are still valid by running each of them. Failing tests are removed from the cache.
On the tool window, in the top corner there exist two buttons: Validate Tests and Toggle Jacoco Report (greyed out). To validate cached tests, the user can press Validate Tests. Validation is going to happen in the background.
validate
Once validated, Toggle Jacoco Report becomes clickable. If clicked, a jacoco table with the updated coverage (so, excluding deleted tests) will appear.
jacoco
jacoco coverage

Accessibility Features

  • The plugin supports changing the color for coverage visualisation and killed mutants visualisation (one setting for both). To change the color, go to Settings > Tools > TestGenie and use the color picker under Accessibility settings:
    Color Picker
  • The plugin has been designed with translation in mind. The vast majority of the plugins labels, tooltips, messages, etc. is stored in .property files. For more information on translation, refer to the contributing readme.

Telemetry (opt-in)

One of the biggest future plans of our client is to leverage the data that is gathered by TestGenie’s telemetry. This will help them with future research, including the development of an interactive way of using EvoSuite. The general idea behind this feature is to learn from the stored user corrections in order to improve test generation.
To opt into telemetry, go to Settings > Tools > TestGenie and tick the Enable telemetry checkbox. If you want, change the directory where telemetry is stored.
Telemetry

Configuration

The plugin is configured mainly through the Settings menu. The plugin settings can be found under Settings > Tools > TestGenie. Here, the user is able to select options for the plugin:
Plugin Settings

First time configuration

Before running the plugin for the first time, we highly recommend going to the Environment settings section of TestGenie settings. The settings include java 11 path, compilation path (path to compiled code), compilation command. All commands have defaults. However, we recommend especially that you check compilation command. For this command the user requires maven, gradle or any other builder program which can be accessed via command. Leaving this field with a faulty value may cause unintended behaviour. Setup

Quick Access Parameters

Some parameters for tweaking EvoSuite are used so often, that going to the settings menu gets annoying. That why these parameters were added (exclusively) to the Quick Access Panel of the TestGenie tool window (Parameters tab). These are settings so common/useful that they deserved their own spot:
Quick Access
❗ Pro tip: don't forget to hit the "save" button at the bottom. ❗

Advanced Parameters

The settings submenu Settings > Tools > TestGenie > EvoSuite allows the user to tweak EvoSuite parameters to their liking. EvoSuite has hundreds of parameters, not all can be packed in a settings menu. However, the most commonly used and rational settings were added here:
EvoSuite Settings

Contribution

The plugin is Open-Source and publicly hosted on github. Anyone can look into the code and suggest changes. You can find the plugin page here.

Licence


Plugin based on the IntelliJ Platform Plugin Template.

testgenie's People

Contributors

actions-user avatar apanichella avatar bolkhod avatar jzelenjak avatar kirilvasilev16 avatar lyuben-todorov avatar martinmladenov avatar mitchellolsthoorn avatar sergeydatskiv avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar

testgenie's Issues

Set up the basic plugin structure

Description

Research the IntelliJ plugin development documentation and set up a basic plugin.

Definition of Done

  • Set up the basic plugin structure
  • Add at least one action
  • Add at least one tool window

Implement tests for the code base

Description

Implement UI tests for the code to ensure the quality/functionality of the plugin and code.

Definition of Done

  • Do you have tests that test the UI of the plugin?

Possible sections to test:

  • Settings
  • Quick Access Tool Window
  • Tool Window coverage visualization
  • Test selection window
  • Have you considered writing tests not just for UI?
  • Can the tests run on GitHub actions?

Set up the link between EvoSuite and the plugin

Description

Create basic integration between EvoSuite and the plugin

Definition of Done

  • Make it possible to generate tests for a (hardcoded) class from the plugin (i.e. execute the same functionality that a command such as java -jar evosuite-1.2.0.jar -projectCP target/classes/ -class delft.ArrayUtils would have)
  • Resolve any issues such as Java version or dependency incompatibilities that would prevent this integration from working

[DUPLICATE] Advanced Settings Button

Description

As a developer, i should be able to access advanced parameters in the Settings menu by pressing the corresponding button on Quick Access tool window panel, so that I can quickly access them in case i want to modify them.

Definition of Done

  • There is a button "Advanced Parameters" on the tool window Quick Access panel
  • After pressing the button, the settings menu with the TestGenie Advanced Parameters tab has to open
  • The button has to work always, no matter if a user has modified anything or not

Plugin Documentation

Description

As a user, I should be able to have access to documentation for our plugin, so that I can learn how to use the tool.

Note: think about different ways of documenting the plugin for the user. Is documentation easy to find? Is there enough of it.

Definition of Done

  • Does the plugin page on marketplace have a description?
  • Is the description complete? Does it have all the necessary features explained?
  • Should some sort of documentation be available from inside of the plugin?
  • Is there a documentation setting/button in the plugin? Is it complete?
  • Does the documentation on the marketplace page match the documentation in the plugin? Should they match?

Create separate build process for custom evosuite builds

Description

Since this plugin relies on a custom build of evosuite to work, the jar is currently sources as a raw binary inside the project's root which is not a good practice. Create a separate build process that allows developers to make custom build releases and integrate it with TestGenie's own build process.

Definition of Done

  • Custom Evosuite build has a separate CI process with artifact releases.
  • TestGenie's build scripts are extended to leverage the above and allows the developers to seamlessly update their evosuite binary without littering the git history.

Settings menu

Description

As a developer, I must be able to change the default parameters, with which I run EvoSuite when I am generating tests. Namely, the following: the list of parameters the client suggested us, continuous test generation, test sequence creation, test execution, class under test, method under test via a Settings menu.

Definition of Done

  • The plugin offers a Settings menu
  • The changes in the Settings menu persist
  • The Settings menu in the plugin allow the user to change default EvoSuite parameters
  • Test the functionality if possible
  • Document your code

Create checkstyle pipeline

Description

Create a CI step that enforces a uniform code style accross the whole project

Definition of Done

  • There is a pipeline step that enforces a single codestyle and doesn't allow unconforming code to be merged.
  • The enforced code style can be checked locally before pushing for convenience

Implement test coverage on the sidebar/toolbar

Description

As a developer, I would like have a quick overview of what amount of my code I tested.

Definition of Done

The following has to be implemented

  • Coverage statistics in terms of absolute values for tested class
  • Coverage statistics in terms of absolute values for tested method
  • Coverage statistics in terms of percentage values for tested class
  • Coverage statistics in terms of percentage values for tested method

Coverage Visualization

Description

As a developer, I should be able to see the visualisation of the coverage in the form of coloured highlights next to a line, denoting which tests cover which lines, so that I can see which lines and/or branches are covered by specific test cases.

Definition of Done

  • User has the ability to visually display which lines are covered by a specific generated test case.
  • User has the ability to visually display which branches are covered by a specific generated test case.
  • User can access coverage statistics (e.g. num. of lines tested) on toolbar window in tabular form

Create a menu for test case selection

Description

Create a menu in the tool window which can be used by other components of the plugin (generating tests for a class, generating tests for a method, etc.) to allow the user to view the generated tests.

Definition of Done

  • In the TestGenie tool window, there is a tab to show generated tests
  • There is a way for other plugin components to use this tab programmatically
  • Each generated test case is showed in a small read-only editor within the tool window (stacked vertically on top of each other)
  • Next to each test case, there is a checkbox to select or deselect the test (selected by default)
  • There is an "Apply" button to apply the selected test cases (no need for actual functionality just yet)

Make visual highlighter change color

Description

Add a color picker to settings which allows the user to change the color of the highlight. This way, the user can use any color they like. Improves accessibility.

Definition of Done

  • Plugin settings has color picker
  • Color picker determines color of highlight in gutter
  • Color picker determines color of highlight in mini-editors

Option to provide a custom Java binary path

Description

Provide an option to supply a custom path to a Java executable instead using the default java as present in PATH.

Definition of Done

  • In the settings menu, there is an option to provide a custom command to invoke a Java binary
  • The provided binary is used when invoking EvoSuite
  • Hardcoded references are removed

Abstract TestGenie to work on multiple IntelliJ editors

Description

Currently, the plugin doesn't differentiate between different editors/workspaces of the user. For example, coverage visualization is always displayed on the editor window that's currently opened, even if the test target is not in that window.

Definition of Done

  • Make switching tabs while tests are generating not break user experience
  • Tie test generation result state to editor instance

Non-java classes

Description

Ensure that calling TestGenie on non-java classes does not throw exceptions and the app does not crash

Note: it might be that no extra work has to be done for this issue. What is important is to verify that the Definition of Done is fulfilled.

Definition of Done

  • Either explicitly hide an option to generate tests when the current file is not a java file, or alert the user that it is not possible
  • No exceptions are thrown and the app does not crash

Custom parameters to EvoSuite

Description

As a developer, I should be able to use a Settings menu for the plugin, where I can set parameters such as Algorithms and Population, so that I can easily specify custom parameters where I want and leave the default ones I do not want to modify.

This issue has been modified to account for the new client requirements, which is reordering the options in the currently existing Settings menu.

Definition of Done

  • Parameters are categorised. Either there are tabs or it is a list with headings
  • There is an option to modify the parameters
  • There is a certain boundary on the parameters, so that a developer cannot set unreasonable parameter values (e.g 1000h on running time)
  • EvoSuite can run with the specified parameters

Option to provide an EvoSuite jar

Description

As a developer, I should be able to have the option to provide an EvoSuite jar executable to my plugin through a settings menu, so that I can actually use the plugin.

Definition of Done

  • In the settings menu, there is an option to provide a path to an evosuite jar file
  • To make it easier for the user to provide the path, a file chooser is shown when entering a path
  • The file path is used when invoking EvoSuite
  • Hardcoded references are removed

Multiple Carets

Description

Ensure that class/method selection for generating tests does not crash when there are multiple carets

Note: it might be that no extra work has to be done for this issue. What is important is to verify that the Definition of Done is fulfilled.

Definition of Done

  • When a user has multiple carets, only the primary one is considered
  • All other carets are ignored

Research UI testing

Description

Conduct research on how to test UI in IntelliJ Plugin. Consider reading the documentation from the intellij-platform-plugin-template and the official SDK. Perhaps implement a demo version of how to do testing on a separate test project.

Definition of Done

  • You read through the documentation from the intellij-platform-plugin-template.
  • You read through the documentation from SDK.
  • You tried to make a demo of how testing might work.

Clickable test names in pop-up which lead to the test (coverage)

Description

For the pop-up, which appears during coverage visualisation in the gutter, create the ability to display tests that cover the line which you click the highlight on. The pop-up already displays the test names, these could be made clickable.

Definition of Done

  • Tooltip which shows, which tests cover a line
  • Names of tests are pressable/clickable
  • Once clicked, the test name leads you to the actual test

Change package name

The package name of the plugin as well as all identifiers must be changed from com.github.mitchellolsthoorn.testgenie to nl.tudelft.ewi.se.ciselab.testgenie.

UI Testing for Quick Access Parameters

Description

Write UI tests for the Quick Access Parameters tab in the tool window

Depends on #64

Definition of Done

  • It is tested that all the elements appear in the tab
  • It is tested that they are clickable
  • Modifying the values is tested as well
  • There are multiple tests, not just one big test for everything

Load defaults from a bundle

Description

As an TestGenie developer, I should be able to load the default values for parameters from a bundle rather than hardcoding them, so that it is more maintainable in case EvoSuite developers decide to change them.

This issue is primarily related to "Quick Access Parameters"

Definition of Done

  • There is a bundle with default values
  • All the hardcoded appearances are substituted with loading the corresponding values from a bundle
  • It is possible to reset the values to defaults (aka it does not break the current functionality)

Apply button makes selected tests appear

Description

Currently, when tests are generated, they appear in the ToolWindow. However, the "Apply" button does not work.
This issue will focus on making it work and actually moving the files in a new test file in the tests folder.

Definition of Done

  • #78
  • Apply button should add the tests to a test file in tests folder.
  • The extracted tests should only be those that the user has selected.

Fix Method and Class Tests generation

Description

During our client meeting, we have discussed generating tests for classes and methods when clicking on them. The client has given us some feedback that we are going to incorporate in this issue (see Definition of Done)

Furthermore, the issue of generating tests for a class and a method from the last sprint must be continued: it is in its very basic version with a lot of limitations (overloads, java or third-party classes and methods). This will also be handled in this issue.

Definition of Done

  • Instead of calling EvoSuite with the method prefix (which tests all overloads), descriptors are used so that only the selected method is tested
  • When clicking somewhere inside a class, there is an option to generate tests for that class
  • When clicking somewhere inside a method, there is an option to generate tests for that method
  • NB! If the above 2 points turn out to be impossible to implement, the alternative would be to generate tests based on the clicked symbol
  • Classes and methods not from the current file are excluded

Test generation for specific lines

Description

As a developer, I should be able to select specific lines in the IDE and tell the plugin to generate tests that cover those lines if they are valid (statements within a method).

Since EvoSuite only supports methods and classes for Units Under Test (UUT) but not specific lines, this feature would wrap around existing functionality and extend on it in the plugin layer.

Definition of Done

  • The plugin is able to call EvoSuite with the relevant parameters so that the coverage goal is as likely as possible to be achieved.
  • The user is not allowed to select invalid lines (like e.g declarations, empty lines)

Make task backgroundable

Description

Make the evosuite runner class leverage Intellij's Backgroundable tasks so that there's a progress indicator shown.

Definition of Done

  • The user has a clear indicator of when evosuite is running in the background.
  • The functionalities expsoed by Backgroundable are proprely implemented.

Testing PSI selection

Description

Write tests for PSI selection (classes, methods and lines). Verify that only the classes that are supposed to be selected are selected, only the methods that are supposed to be selected are selected and only the lines that are supposed to be selected are selected.

Definition of Done

  • Class selection is tested
  • Only the allowed classes are selected
  • Method selection is tested
  • Only the allowed methods are selected
  • Line selection is tested
  • Only the allowed lines are selected

Assertion Generation

Description

As a developer, I should be able to provide the assertions that the generated tests should make use of, so that the algorithm can generate better tests and use better assertions in the future.

Note: this feature was tagged with an asterisk in the google doc, it had comments from Martin and Mitchell.
A few implementation things are unclear at the moment, i.e. how should the developer provide the assertions, where, should the developer be notified of successful input?
For more clarification refer to "Assertion Generation" feature in ProjectForum project description.

UPDATE: after implementing the new features introduced by the client and having a discussion, it has been decided that our part of this issue is going to be implementing telemetry diff specifically for changes made in assertions.

Definition of Done

  • After modifying and applying the tests, if the telemetry option has been enabled, changes made in assertions are identified and stored in the telemetry file
  • The functionality is integrated with already existing telemetry collection

Separate DTOs from Thunderdome

Description

Currently, the DTOs that we use (such as CompactReport) require us to import the entirety of EvoSuite into the classpath. This is not optimal, so it would be best to move those shared DTOs to a separate module, which can then be imported both to Thunderdome and to TestGenie.

Definition of Done

  • A separate common module is created
  • All common DTOs are moved to that module and referenced in Thunderdome and TestGenie

Generated tests tool window shows syntax errors

Describe the bug
When the generated tests tool window is updated, it shows an "Unexpected tokens" syntax error over all tests.

To Reproduce
Steps to reproduce the behavior:

  1. Generate tests for a class or a method
  2. Open a different tool window alongside TestGenie's (e.g. the Maven tool window)
  3. Look at the syntax errors and red underlining in the generated test text boxes

Expected behavior
No syntax errors are shown

Screenshots
image

Sidebar Tool Window for Quick Access to frequently used parameters

Description

As a developer, I must have a quick access to ~10 parameters in the side bar (tool window), so that i can easily and quickly tweak them.

Definition of Done

  • There is a tool window tab
  • All the selected parameters are present in the tool window tab
  • Parameter values are synchronised with the values in the settings tab by sharing the state

Refactor evosuite runner

Description

Runner.kt is in dire need of a refactor. Currently the class has a lot of code duplication and a lot of inefficient usage of IDE real estate. This is a class that should have little to no runtime dependencies or mutable state (the only exception being if the user wants to use a custom java path than their system's default). However, due to the limitations of the build system, it doesn't seem to be possible to inject the required constants which are known at compile time.

Definition of Done

  • Code repetition is removed
  • Class is refactored to be convenient to use, i.e. a chainable builder pattern

Fix Quick access & method/class parameters

Description

Our client has given us feedback on the relevance of the parameters in our quick access window. Some of the parameters that we have included in the previous sprint are actually rarely (if at all) modified (like e.g local search budget). This issue will focus on incorporating their feedback and correcting the problems.

The fixes should ensure that the code is consistent throughout the entire code base, i.e. if we are removing a certain parameter from the quick access then we should make sure that it is removed correctly in all the places where it is no longer relevant/used.

Definition of Done

  • The name of the section (the title) has changed from "Frequently used parameters" to "Quick Access Parameters"
  • The parameters have been placed in the correct order, according to their priorities (e.g search budget is the first);
  • Clear sections for the groups of the parameters have been created, according to the client (search budget, timeouts, population)
  • search budget and stopping condition have been placed in own category (since they are related).
  • It has been made clear that stopping condition is referring to the budget type of search budget (rename or extend a tooltip)
  • search budget has a dynamic unit depending on the selected type
  • Parameters tab has been placed to the last place in the tool window
  • The code works and compiles

UI Testing for Coverage Visualisation

Description

Test the Coverage Visualisation offered by TestGenie.

Definition of Done

  • Test coverage visualisation is generated when tests are generated.
  • Test a new toolWindow tab is created.
  • Test the table in coverage visualisation tab has correct data.
  • Test (if possible) that the gutter is working properly. Turned out impossible, because IntelliJ does not support tests for gutter.
  • Test (if possible) that the gutter hyperlinks are working properly. Turned out impossible, because IntelliJ does not support tests for gutter.

UI Testing for Settings

Description

Finalise testing the Settings menu from the previous sprint.

Definition of Done

  • All components of Settings are tested.
  • The state persistence is tested.
  • Tests for business logic of Settings.
  • Fix bugs if any are discovered during the testing process.

Smarter variable names in tests

Description

As a developer, I could have my variables names in the generated tests be based on their usage, not just by their type (e.g if a string is passed as an argument of a method and that argument is named “username”, then the string in the test will also be named “username”), so that it is easier for me to read the generated tests.

UPDATE: after implementing the new features introduced by the client and having a discussion, it has been decided that our part of this issue is going to be implementing telemetry diff specifically for changes made in variable names.

Definition of Done

  • After modifying and applying the tests, if the telemetry option has been enabled, changes made in variable names are identified and stored in a separate file
  • The functionality is integrated with already existing telemetry collection

Method selection for testing

Description

As a developer, I must be able to manually select a method via TestGenie and generate tests for that method.

Definition of Done

  • EvoSuite can be run through plugin (duplicate from #7 )
  • Methods are selectable through plugin
  • Tests on specific methods can be generated through plugin
  • It is possible to pass the persisted values of the parameters to EvoSuite
  • The functionality is tested, if possible.

Depends on #7

Class selection for testing

Description

As a developer, I must be able to manually select a class via TestGenie and generate tests for the entire class (i.e all its callable methods).

Definition of Done

  • EvoSuite can be run through plugin
  • Classes are selectable through plugin
  • Tests on specific classes can be generated through plugin
  • It is possible to pass the persisted values of the parameters to EvoSuite
  • The functionality is tested, if possible.

Add a link to settings from quick access tool window tab

Description

As a developer, I should be able to access advanced parameters in the Settings menu by pressing the corresponding button on Quick Access tool window panel, so that I can quickly access them in case I want to modify them.

Definition of Done

  • The name of the link is clear or named the same as the settings section in Settings
  • The name has been placed in an intuitive place on the page
  • The link works. When pressing the link it opens the IntelliJ Settings, in particular the EvoSuite/TestGenie Settings

Providing jar

Description

As a developer, I should be able to have the option to provide an EvoSuite jar executable to my plugin through a settings menu, so that I can actually use the plugin.

Definition of Done

  • There is a Setting menu for selecting a jar executable
  • The jar can be used to running EvoSuite

Hide generated tests tab until tests are actually generated

Description

The generated tests tab is currently empty. This tab should not appear until tests are actually generated.

Furthermore, the "Generated tests" tab should be the one that is focused once test generation is complete, rather than the "Coverage visualisation" tab.

Definition of Done

  • Hide the generated tests tab until tests are generated
  • The "Generated tests" tab should be the one that is focused once test generation is complete, rather than the "Coverage visualisation" tab

Interactive learning

Description

As a developer, I could be able to conduct interactive learning via TestGenie using gathered feedback (e.g provide a proper string format (e.g regex) if the test generator used a wrong string format), so that it can be passed to the EvoSuite application in order to improve the quality and efficiency of the next generated tests.

UPDATE: after implementing the new features introduced by the client and having a discussion, it has been decided that our part of this issue is going to be implementing telemetry diff

Depends on #6 #10

Definition of Done

  • After modifying and applying the tests, if the telemetry option has been enabled, changes made in tests are identified and stored in a separate file
  • The functionality is integrated with already existing telemetry collection

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.