I am running some Selenium tests on a Java project using Gradle. I would like to have 2 different Gradle tasks: one to run the tests using the local WebDriver and one to run the tests against a RemoteWebDriver (which will hit a Selenium Grid server). Right now I have a base.properties flag called useRemoteDriver that I can set to true or false to run local or remote tests.
Is there a way I can get a Gradle task to either change this property on execution or is there another way I can accomplish this?
If I understand this right, you want a property which has a default value but you can override when calling gradle in the command line.
I use a similar setup where I declare
env=Dev
In my gradle settings file and have the option of supplying
-Penv=Production
Via the command line to gradle
Related
We are in the process of upgrading all of our tests to use JUnit 5. Previously we had to set the test.workingDir so that our tests would work the same in Eclipse and Intellij IDEA. Now that I'm using JUnit 5 I'm running into issues with this. I've gone through the JUnit 5 Gradle documentation, but have found no way to set the workingDir for the tests. This causes issues because the tests run differently in the IDEs than they do in the command line.
That Gradle plugin adds a task of type JavaExec called junitPlatformTest. So configure it using junitPlatformTest.workingDir = ....
Besides that, you should maybe rewrite your tests to not depend on the current working dir, but using classpath lookup to get files you need with methods like getResource() and getResourceAsUrl().
Is there any jenkins property which can i access in my java code to identify that code is running on jenkins ? I have around 1000 of test cases running on different jenkins CI, which is managed by different teams. I dont want to set any manual flag or string properties in each of my jenkins build, There should be some property which can be use to identify this ?
You can take a look at this page which calls out all the environment variables that are exposed by Jenkins. So you could have your Java code query any of these environment variables to determine if the java is being run in a Jenkins environment or is it being run from a dev box or an IDE even.
I have configured unit testing for AndroidStudio as described on the Android documentation (http://tools.android.com/tech-docs/unit-testing-support).
I would like to run every test method in its own JVM, so all static properties in my project are set back to their default values.
I couldn't find anything about this in the documentation and I'm afraid this is not possible yet.
I'm running my tests from the command line (gradlew --daemon test) as I didn't get the testrunner in Android Studio to work.
Does anyone know how to fork every testmethod in its own jvm process, so they run 'standalone'? Please let me know if this is possible or if there are alternative ways to run every testmethod in it's own process using gradle.
Thats easy. In your test task set
forkEvery 1
That will cause a new jvm to be forked for every single test.
I'm using Netbeans with Maven and TestNG. When running tests with the maven surefire plugin, I can setup some configuration parameters, in particular the logging level used for my tests (trace):
-Dorg.slf4j.simpleLogger.defaultLogLevel=trace
-Dorg.slf4j.simpleLogger.logFile=System.out
However, when running a specific test file (CTRL + F6) or test method ("run focused test method"), Netbeans does not use surefire (which is good) and therefore ignores those parameters.
Is there a way to change the JVM parameters used by Netbeans when it runs tests that way?
This is somewhat similar to this other post but my question is specific to Netbeans.
From the documentation of Netbeans 7.2 (see Netbeans 7.2 changes, section Maven) :
... Now Test File always runs Maven by default, just like Test Project ...
What version of Netbeans are you using? Probably you should just upgrade to 7.2.
In the Project Properties, you can create profiles under Run. In theses profiles you can customize VM Options. You can add your parameters here, create a Test config and Run config.
Set fork property in the surefire plugin configuration in Maven. This will start a new JVM. Now, the second part is how to read the JVM parameters that you want into the new JVM. Depending on what you want to do, you might need to be read them from the environment.
In my case i went to project/properties, then "Actions" category. There you'll find "Test file" and "Debug test" actions. Select them and place whatever properties you need in "Set properties" box.
Not sure if this is only applicable for Maven projects...
I am trying to run an automated suite every day at the same time, so I want to create a task to open eclipse and execute the main script every day. Is there a way to do this from the command line?
Instead of using eclipse for it, use a software that is dedicated for it - continous integration servers are created for it. Check such titles like: hudson, cruiseControl, TeamCity
You are on the wrong path. Instead of trying to automate opening eclipse, executing a main... break the IDE dependency, write a portable build script using Ant or Maven and execute that build script outside the IDE (using a simple cron job or something more elaborated like a Continuous Integration tool but I'm not sure you need a CI tool for now, start with the build script).
So I am assuming that you want to automate something that you run from inside eclipse. if it's a build then I'm with the other guys that using a build script and CI is the way to go.
But in case it's not that use case...
Now, if you are using the "Run.." dialogs to do this you can actually get the command line paths, binaries and arguments that eclipse used to execute.
What you do is open up the debug perspective. Then run your script however you normally do.
Your Process should appear in the "Debug View" at this point.
Either while the process is running or after termination, right click on the process and open up the properties. (you may need to click 1 level down in the tree to get this option)
Under process info, inside of that there is a section "Command Line". This is the exact command line that eclipse executed behind the scenes to run.
you should be able to put this into a script (.bat for windows / sh for *nix) and schedule accordingly.
edit: added in assumptions, changed to use process info terms which is what is on the properties screen.