We Keep Coding

Azure/IntelliJ shows runScenario instead of actual test name using Cucumber

I have just added my cucumber test to an Azure pipeline. After running the pipeline I noticed that my cucumber tests are showing up as runScenario instead of the test name.
If I click on the runScenario and I go to Attachments I do see that it shows my test scenario there.
If I run it in IntelliJ my tests shows up as runScenario []
I've googled a bit but cant seem to find how to fix that. Any idea how to show my test scenario or Feature?

On your Agent job tasks I used Maven.
In the configuration under JUnit Test Results add the path to your Junit result (Should be an .xml file). For me specifically it was under:
$(System.DefaultWorkingDirectory)/<project>/target/cucumber-junitReports/Cucumber.xml

Why does ":project:testXlib" replace the ":project:test" Gradle task and how does that work?

Environment
I'm currently trying to run JavaFX GUI tests via xvfb on multiple environments on Travis CI. I'm using Gradle to run these tests while using the TestFX and NestedRunner testing frameworks to write them. Before running the tests, export DISPLAY=:99.0 is called.
Context
There are times when the build succeeds and other times when it fails. However, I've noticed that Gradle outputs a single line that I can use to predict when the build will succeed or fail.
Before that line appears, one will see the following in the Travis CI log:
:richtextfx:compileJava
:richtextfx:processResources
:richtextfx:classes
:richtextfx:compileTestJava
:richtextfx:processTestResources
:richtextfx:testClasses
After that, one of two lines appears that predicts whether the build will succeed/fail:
on success: :richtextfx:testXlib: extension "RANDR" missing on display ":99.0".
on failure: :richtextfx:test
My Question
Why does Gradle change the test task to testXlib task? What are the inner mechanisms that handle this? And what does it all mean?

Gradle for sure does not do this. I've never heard of a task called testXlib and also the complete Gradle source does not contain this character sequence.
Either your build script does this, or some plugin you apply, or an init script that is applied by Travis CI.
Try to increase the logging level to debug and also add a call to tasks --all, maybe that will shed some light.

Access teamCity Build number in Java

I am running my automation test suite from TeamCity. I need to access the buildId property as I have a situation where I have to construct a file path using this buildId.
I tried using System.getProperty("teamcity.build.id") but it just displays null. How can I access the buildID of the current team city run from my automation code which is written in java.

You can pass it while running the build step, using %build.number%.
https://confluence.jetbrains.com/display/TCD5/Predefined+Properties

Change default "Program to Run" in Eclipse launch configuration

every now and then I am launching JUnit tests from within Eclipse by using
Run As > JUnit Plug-in Test
By default Eclipse assumes you are running something which requires a workbench and chooses in the "Main" section of the launch configuration
LaunchConfig > Main > Program To Run > Run an application >
org.eclipse.ui.ide.workbench
I can understand why this is the default, but for me (and for all in our team) this is never ever the case. We always need to run our JUnit Plug-in Tests as
LaunchConfig > Main > Program To Run > Run an application >
[No Application] Headless Mode
How do I change this default behaviour?
I am currently using Eclipse 4.4.

It seems a custom LaunchConfiguration-Extension is a viable solution attempt.
What I did was to create a new, custom LaunchConfiguration-Extension which is 99.999% build on the JUnitLaunchConfiguration. I only had to add a custom
BlaBlaJUnitPluginTestLauncher extends launching.JUnitLaunchConfigurationDelegate
which overrides the
launch(ILaunchConfiguration, String, ILaunch, IProgressMonitor)
method to adjust the application parameters according to our needs.
BlaBlaJUnitPluginTestTabGroup extends org.eclipse.pde.ui.launcher.JUnitTabGroup
To be able to initialize the LaunchConfig dialog with the default parameter, I had to:
Add a custom BlaBlaPluginJUnitMainTab extends PluginJUnitMainTab
Create a custom JUnitProgramBlock implementation (BlaBlaJUnitProgramBlock)
Creating an instance of BlaBlaJUnitProgramBlock in the BlaBlaJUnitPluginTestTabGroup.BlaBlaPluginJUnitMainTab.createProgramBlock() method
Overriding setDefaults-method (not sure if its really neccessary) in BlaBlaJUnitProgramBlock
Overriding initializeForm-method in the BlaBlaJUnitProgramBlock and adjust parameter there too.
Leading to the following result:

This answer is a near miss:
Try this:
Manually create and configure one "good" launch configuration.
Next time you want to launch a test that doesn't yet have a good launch configuration:
Select the file and invoke Run As > Run Configurations ... (i.e., don't yet select JUnit Plug-in Test!)
In that dialog select a good launch configuration of the same kind, and ...
Then click New Launch Configuration (upper-left corner)
Now the newly created configuration should "inherit" the configured values from the the good configuration.
Truth is:
You can duplicate an existing launch configuration (leaving you to manually select the test to launch)
The Debug team once had plans to support launch configuration templates.
Edit 2018:
Since Eclipse Photon, the Java debugger supports launch configuration prototypes. I just filed Bug 536728 to request this also for test launches. Feel free to chime in (or contribute) on that bug.

if u r looking for only shortcut for convenience then eclipse remembers last execution. After using run as and saving ur run config, just use "Run as" button in toolbar.
besides this eclipse comes with flavour for testers, u can check that out.
Also since you are talking about unit testing see if you can make use of ant build or even better converting to maven based project. Maven has integrated support for testing.

There seems to be a simple and effective heuristic in place, which decides whether or not a JUnit Plug-in Test should be run headlessly or with an application:
Make sure that the plug-in containing your tests has no dependencies on anything org.eclipse.ui.
Without that dependency [No Application - Headless Mode] is selected by default for newly created launch configurations.
With that dependency the default is Run a product, with s.t. like org.eclipse.platform.ide preselected.

Detect application mode (DEV, TEST, PROD) during build in Play Framework 2.x application

Good day all,
I'd like to be able to detect the mode that a Play application will use during build. Meaning I'd like to execute certain tasks within my Build.scala/build.sbt depending on whether the application is started in DEV or in PROD mode for instance.
The reason I need this is because we (the team) have implemented Grunt.js into the build process by adding it to the playRunHooks. Depending on whether the application is running in DEV mode or not we want to enable/disable some Grunt tasks.
I know I can check the application mode from within the actual application using Play.isDev and the like, is there a similar mechanism available for within the build files?
If not I would really only need to know the command that was issued by the developer (run, start, dist, stage etc.) but I can't seem to find a straight forward way of getting to know this either.
Can anyone point me in the right direction? Thank you in advance!

Any build tasks that are added to playRunHooks are only executed on "play run". If you do "play stage" or "play dist" those tasks are never executed.

The reason I need this is because we (the team) have implemented Grunt.js into the build process by adding it to the playRunHooks. Depending on whether the application is running in DEV mode or not we want to enable/disable some Grunt tasks.
Since you say build process and are looking to hook into the application when it's running in prod mode I think the place you're really looking to hook into is the dist command. In that case you'll want to create some tasks for your build file and get creative with .dependsOn to incorporate them.
SBT has a way of running external processes such that you could define a simple inputKey in your build.sbt file like so:
val doGulpRelease = inputKey[Unit]("Runs gulp --release")
doGulpRelease := {
val s = streams.value
s.log.info("Preparing to run my task")
"gulp --release" ! s.log
s.log.info("Done with my task")
}
Then, to hook into the dist process of play, you can set it to depend on a task created from the above:
dist in Universal <<= (dist in Universal).dependsOn(doGulpRelease.toTask(""))
This will cause your dist command to also run your custom build command, which in this case would do whatever the release task was defined to do.
In the same vein, if you need some build process to run for your tests, use test in Test and dependsOn to run whatever you need to. It seems to me you're asking an XY problem but if is the case that you're not and you really do need to run grunt subprocess's from within your running play app then you'll need to use the Global Object and hook into the onStart/onShutDown hooks and create some type of job runner for yourself. You could start here for some hints on running background tasks in play and besides that google is your friend.
Note: You may need to do some imports at the top of your build.sbt file to use the above code, and it will also depend on your sbt version, but with 0.13.5 I believe it is:
import sbt.complete._
import complete.DefaultParsers._
import com.typesafe.sbt.packager.Keys._