Incompatibility with Gradle 4.0 - Test.getTestClassesDir() returns Java test classes only

[jthurne]

I tried using the gradle-scalatest plugin with Gradle 4.0 (recently released), and it seems to work except that no tests are ever executed. After a bit of digging, I discovered it is because in Gradle 4.0, Test.getTestClassesDir() has been deprecated with a replacement called Test.getTestClassesDirs() (note the plural form of Dirs).

It looks like Gradle 4.0 now produces separate class compilation directories (including test class directories) for each source set. Since there are separate source sets for Java and Scala code, there are now separate test class directories for each of them (build/classes/java/test and build/classes/scala/test). Unfortunately, getTestClassesDir returns only the first test class directory, which always is the Java test dir. This means that ScalaTest is executed using the Java test class directory, and of course, doesn't find any ScalaTest suites.

Probably the best fix is to check for Gradle version 4.0 or higher, and if 4.0, then use Test.getTestClassesDirs instead, and pass them all to the -R ScalaTest flag (with proper platform path separators of course).

Unfortunately, Test.getTestClassesDirs was introduced in Gradle 4.0, which is why you cannot just switch to using it exclusively, as that would break compatibility with earlier versions of Gradle.

[maiflai]

Yes, quite correct - it seems that the integration tests are lacking in this area.

I'm taking a look, hopefully I'll be able to get a release out soon.

For what it's worth, I'm not sure you can deprecate something and change its behaviour at the same time, but that seems to be what has happened?

Cheers, Stu.

[jthurne]

For what it's worth, I'm not sure you can deprecate something and change its behaviour at the same time, but that seems to be what has happened?

Yeah, it's a bit of a grey area in this case. From one perspective, the method still does what it did before...it just doesn't return more than one directory. Given that the method returns a java.io.File, it's also hard to imagine how they would have modified that function to return two directories.

I suppose this is one reason why the Gradle team decided to increment the major version (to indicate that there were breaking changes).

In any case, Gradle 4.0 is hot off the press, so the impact of this right now is pretty small (and hats off to you for fixing it quickly!)

[maiflai]

I've published 0.16, which should be available on Central shortly.

Please could you let me know if it addresses your issue?

Thanks, Stu.

[sinwe]

0.16 seems to be working for classes but not resources

[jthurne]

0.16 definitely works for Gradle 4.0 (for classes at least). I'm still testing to see if it works on earlier versions of Gradle.

[maiflai]

Great, thanks.

I'm not sure I follow what you mean by "not working for resources"?

[sinwe]

My test directory structure is as follow:

. +-- src\ ----+-- test\ --------+-- resources\ --------+-- scala\

When I run using gradle 4.0, the test\resources will be copied at .\build\resources\test\ however it seems gradle 4.0 set the classpath to .\build\resources\test\java. Therefore the required resources are not available on the test classpath.

[maiflai]

The indentation appears to be lost in your message.

Is the repository publicly available for me to take a look at please?

[sinwe]

I've updated my comment. Unfortunately the repo is private internal repo in my company, so public can't see it.

[maiflai]

Ok, that complicates things a bit.

I hope that https://github.com/maiflai/gradle-scalatest/blob/master/src/test/examples/jacoco/src/test/scala/HelloSpec.scala (and the passing build) shows that this plugin does make both main and test resources available on the classpath.

Can you create a sample project demonstrating the problem please?

[sinwe]

Hi, after some investigation, I believe the issue I encountered is nothing related to scalatest. It is some weird code in the existing code that caused it.

[maiflai]

Thanks - in that case I'll close this issue