Develop Reference

Test Runner class takes long time to build each time a code change is made

Test Runner class takes more than 5 minutes to build and launch each time I change some code in my Maven project with a Cucumber framework.
Could I be pointed to what may cause this problem and what would be the solution to this?
Loading Image :

I would like to guide you on few things related to cucumber speed and leave one thing which may speed up build and execution time initially.
Configuring the eclipse.ini - Go to your Eclipse setup folder & open
eclipse.ini and update these 2 parameters as -Xms256m & -Xmx2048m (more memory) The Xmx argument is the
amount of memory Eclipse will get (in simple terms). With -Xmx384m,
it gets 384 MB of RAM, with -Xmx4G it gets 4 GB, etc.
In most projects I know, Cucumber test suite speed is not an issue. Of course, running 400 features takes its time, but still each test for itself is reasonably fast. There is nothing you can do to fundamentally speed up such a test (of course, you should be using parallel tests execution).
Cleaning up history and indexes reduce the load on RAM, and overall HDD usage as well. This result in very high impact on performance. To remove the indexes and history folders, please cleanup all files/folders inside these two folders:
For cleaning up indexes - {workspace path}.metadata.plugins\org.eclipse.jdt.core
For cleaning up history - {workspace path}.metadata.plugins\org.eclipse.core.resources.history
Here {workspace path} is the path of eclipse workspace where you create all projects.
Performance Factor While Opening Feature File - It does seem though that the opening time is proportional to the number of step definition files in the project (or the package defined for where the plugin should look for steps definitions).

Errai (GWT) compilation is too slow -- how to make is faster

Tested on a 3.2 GHZ Quad Core machine with 4GB DDR3L, running GWT with the following commands takes a very long time:
First
mvn gwt:devmode
Second
mvn war:exploded
2-3 minutes for running dev mode, and another few minutes for compilation starts in the browser. It's almost 5 minutes for every run and test.
What Maven configuration could work to make the GWT compilation faster?

First you can set it to build for one browser only. Add this to the modules '.gwt.xml' file:
<set-property name="user.agent" value="gecko1_8"/>
(Other user agents can be found here https://gwt.googlesource.com/gwt/+/master/user/src/com/google/gwt/useragent/UserAgent.gwt.xml)
Another optimisation is to let gwt use more than one core when building. When you 'GWT Compile', on the advanced under 'Additional compiler options' add:
-localWorkers -8
Or the amount of thread you want to use.
Lastly, if your project contains multiple modules, each with their own entry points. You do not have to rebuild each one of them every time. Only the one you are working on. I have a project with 15+ modules and only build one at a time unless I have made a change to shared data in another module.
It's just as easy to remove modules from the 'GWT Compile' as it is to add them.
With the above being used you will get a build time of between 5 and 15 seconds.

Gradle taking time up front seemingly doing nothing

Gradle seem to be really slow for me and I have no idea why.
Whenever I run a build it takes like 30 seconds for me, according to the output 25 seconds of those it's doing nothing.
Building like this:
gradlew build --parallel --offline
This is happening to me now with Kotlin, it was the same when I was using Java only, incremental builds don't seem to do anything either
EDIT: I have the gradle daemon enabled
Every subsequent build right at the start takes as long or longer than starting the daemon apparently doing nothing
This is my Project: https://github.com/forsakenharmony/GameProt

I recommend starting with some measurement:
gradlew build --profile
Open up /report/profile in a web browser and see what it's doing.
It sounds to me like your project is taking a long time to configure. Do you have a large project or many projects in your build? Are you using a bunch of plugins?
The easy way to reduce configuration time is to configure fewer things. Remove plugins that you only use rarely. Try out the #Incubating --configure-on-demand option.
Come back after you've confirmed via profiling for further help.

You can try enabling gradle daemon.
That way gradle won't have to load from scratch every time you start a build. Instead, it will run in background waiting for a build to start.
org.gradle.daemon=true
in «USER_HOME»/.gradle/gradle.properties

Continuous testing with IntelliJ Idea

I'm looking for an IntelliJ IDEA plugin that would run my tests each time I change my code. I looked for such a solution and I found:
Infinitest, which works, but is inconvenient because I need to add the facet to each module, and it opens a new tool window for each module (which means 15 tool windows for me).
Fireworks - didn't work for me, maybe it just doesn't work with IDEA 14 (in its repo I can see that last changes were made in 2009). IntelliJ also reports that it throws exceptions.
There are lots of ways I could run all my tests (including writing a simple script for this), but I'm looking for a tool that would be smart enough to rerun failed tests first, and that would understand module dependencies (so after a change in some module it would run only tests of dependent modules).
I prefer free options, but if there's something paid for a reasonable price, I would accept it as well.

IntelliJ now actually has a Toggle auto-testin the run dialog. Just run a run-configuration and then select Toggle auto-testin the run dialog.
It's not as intelligent as you would have hoped. It just reruns when it detects changes.

I know this is a 3-year-old question but I think it will help people who face the similar problem in future. So I found out a way to enable SBT style auto test execution in IntelliJ studio.
We need to do 2 things to enable auto test execution.
Enabling auto project build - This can be done in settings by going into File -> Settings -> Build, Execution... -> Compiler and selecting "Build Project automatically".
Enabling "Toggle auto-test" in run dialog box
This will start auto testing. Although this works fine, it takes time to build the project even when my project is tiny so for larger projects it will certainly take very long time to complete the build and execute tests.
Reference: Original article which explains these steps

If you are OK running tests which cover a single method chosen by you, you can try this plugin (it is continuos in the sense that you make changes to a method, then click on the method and the plugin will run all the unit tests automatically which cover that method): https://plugins.jetbrains.com/plugin/15063-unit-test-coverage-history-runner

You can use the Intellij Teamcity plugin. Teamcity is a paid product but there is a free version which gives you 20 projects and 3 agents for free .
It has a remote run feature using which you can send in unchecked code to run tests before committing.
It also has options to run failed tests first
Usage instructions for Remote Run

Avoid error when running java tests which generate super long command lines?

I get a:
Exception occurred executing command line.
CreateProcess
Cause by a too long commandline (too many libraries, too long path to the jars) when running from eclipse.
The only solution for me is to go to run as configuration... then create a configuration, remove all default dependencies and manually add only the things which are required, so the commandline does not get cut off.
I normally do this for jUnit tests.
This is a waste of time, is there a different solution?
thanks

If you're on java >= 6 you can use classpath wildcards.
That should be enough unless you have your jars scattered around the filesystem, which would call for some cleanup.
edit
If you're simply running junit tests with run as junit test in eclipse then you can define 'user library' and add that to the classpath. Haven't tested it though, and it might suffer from some limits on environmental variable length in windows, but i think that's the safest bet.
edit2
You can try this plugin mentioned in this answer. It worked on indigo, so i guess it will work on helios.

You can play around with forking settings - if you do not fork junit execution, you should be fine. However, classpath management in eclipse is a big mess - it does not separate production and test scopes.
Real alternative would be working maven build, which you should have, as eclipse is not a proper building tool - surefire plugin provides anough alternatives to overcome classpath environmen shortage.