How do I set the working directory for TestNG in a multi-project gradle build?

Old Forum
1

The documentation for Test.workingDir says: The working directory for the process. Defaults to the project directory.

When I output the workingDir, it looks OK as it is set per subproject, which is what I actually want.

test {

useTestNG()

systemProperties = System.properties

println "WD for tests of subproject " + project + " is " + workingDir }

But in my test code the Java working directory is obviously set to the project dir of the root project, breaking my tests. Is there a test-ng-specific option to set the workingDirectory for the test run or what else am I doing wrong?

I also posted this on stackoverflow too quickly so ignore that, if you come across it twice.

Thanks

2

Seems not many people are using gradle + TestNG.

Is this the right place to ask such a question or is there something else like a mailing list that I could post this to?

3

hello robert, this is the right place to ask. you can change the workingdir for testng tests with

test{
   useTestNG()
   workingDir = ....
}

have a look at the DSL reference of the test task for details.

cheers, rene

4

Hello Rene,

thanks for the reply.

However, there must be a misunderstanding. In my posting I wrote that when I output the workingDir (see code example) it is set as I would expect, i.e. to the subproject dir but when my TestNG test is executed by the test task, it is not set to that (I can output new File(".").getAbsolutePath() and that is the directory of the root project).

Regards,

Robert

5

Gradle is forking a vm for executing your tests in a seperately. Where do you put the output of “File(”.").getAbsolutePath()"? if you do this in your gradle script you will just see the currentDir of the build you’re running and not the workingDir of the forked test vm.

6

No, I put the output in the TestNG test method.

7

Loading from the filesystem using relative paths during unit tests is problematic because different environments will set a different working directory for the test process. For example, Gradle uses the projects directory while IntelliJ uses the directory of the root project.

The only really safe way to solve this problem is to load via the classpath. Is this a possibility for your scenario?

8

I don’t see a problem with this in my case. I need this to work in gradle and in IntelliJ. In IntelliJ I can set the working directory in my run configuration and in gradle I thought I could do the same in the test task, so all bases would be covered. If for some reason this does not work in gradle, I have to come up with something (like classpath) to work around this but if it is not necessary I would like to avoid having to change all my tests now but it is definitely doable.

9

Then syncing ‘test.workingDir’ to the IntelliJ setting will do what you need.

10

Have you read the initial post?

I output the default value of test.workingDir and it is what I want but it does not get set to that in the VM that is spawned for the test (see above). This does look like a bug in gradle or I am missing something not so obvious.

To make misunderstandings less likely

Lets presume I have this filesystem setup

wherever/rootProject/projA wherever/rootProject/projB

Where rootProject is the project dir of the root project and projA and projB are the subprojects in my multi-project build.

When I output test.workingDir (default, I am not assigning it to anything) in gradle it gets set to

wherever/rootProject/projA for projA

and wherever/rootProject/projB for projB

Perfect, because that is what I want and how I would interprete the documentation of test.workingDir. However in the Java test code for tests in projA and those for projB, when (for debugging purposes) I output new File(".").getAbsolutePath(), I get wherever/rootProject in all cases.

11

Best thing to do at this point would be to push something to GitHub or similar that exhibits the problem.

Best I can guess is that some plugin or configuration is changing the value at the last minute. This is something that is tested, so a bug is unlikely.