Add ability to run Java tests

[raymank26]

By now this plugin redefines test task which is OK for Scala tests only. But when module contains Java tests there are no easy way to run them. As a workaround I suggest to rename test task to scalaTest for example.

[maiflai]

Sorry, this scalatest plugin is not designed to work in parallel with the normal gradle java Test task, it is designed to replace it.

It writes reports and other files into the same locations as the java Test task; you cannot directly use both in the same project.

If you require this behaviour then I suggest the following in your build file:

// apply plugin: 'scalatest' - do not actually apply the plugin, but you still need to add it to your buildscript classpath.
import com.github.maiflai.ScalaTestAction
task scalaTest(type: Test) {
    actions = [ new ScalaTestAction() ]
    reports {
        html {
            destination = file("$project.buildDir/reports/scalatest")
        }
    }
}

Please could you let me know if this works for you?

[emlun]

@raymank26 You can run your ScalaTest tests using JUnit instead, like this:

import org.junit.runner.RunWith
import org.scalatest._
import org.scalatest.junit.JUnitRunner

@RunWith(classOf[JUnitRunner])
class MySpec extends FunSpec with Matchers {
  describe("A zero") {
    it("equals another zero") {
      (0) should be (0)
    }
  }
}

And in your build.gradle, just apply plugin: 'scala' and your ScalaTest test should be detected automagically (assuming you're using the conventional project layout with sources at src/main/{java,scala} and tests at src/test/{java,scala}).

[maiflai]

Thanks - yes, that is an option.

In the past I've found that developers forget to include the annotation, which means that they can run the test from their IDE but the CI build will then ignore them.

The common workaround is to create a base trait for all your tests, but developers can still forget to mix it in.

You might also move the java tests to a separate subproject, or actively refactor them to scalatest.

[maiflai]

Closing due to inactivity

[jnadler]

I have this exact issue. @maiflai I tried the import... workaround you mentioned above but this fails in our multi-module build:

 :common:scalaTestConsole
 Error: Could not find or load main class scala.tools.nsc.MainGenericRunner
 :common:scalaTestConsole FAILED

I tried adding the scala library as a buildscript dependency but this did not help. Still searching for a way to run both Scala and Java tests.

I totally agree with your concern about using @RunWith - developers will forget to use it and it would be so easy to never notice, because the unit tests still pass.

[maiflai]

I think you've run into this issue: https://github.com/maiflai/gradle-scalatest/issues/17#issuecomment-96410351. Gradle is trying to launch the Scala REPL.

Unfortunately the REPL doesn't work out of the box, you need to modify your project as per http://sethrylan.org/2013/07/02/scala-gradle-scalaconsole.html if you really want a REPL.

My personal opinion is that the best way to run the junit tests is to move them to a separate subproject and use the normal gradle junit runner.

[radimk]

I do not like the idea of moving junit tests into separate subproject (or moving scalaTests for that matter). It splits parts that logically belong together (code and its tests). It makes it harder to easily reuse test fixtures creates and obstacle for simple development.

Defining a new sourceSet to have main/test/scalaTest would be simpler to accept. This again leads to two tasks: test running JUnit/TestNG tests and scalaTest running scalaTests (as outlined in first maiflai's comment here). check would depend on both of them. But then when you look at it it not really necessary to split the sources. I think having an option to replace default test task or to add a new one would be great addition. Like

scalaTest {
  reconfigureTestTask = true/false
}

[maiflai]

Can I ask why do you have two distinct testing frameworks in a single project? How does a developer know which one he should use?

[radimk]

Legacy. Migration from Java to Java+Scala development means you inherit some tests and their rewrite is additional work to do.

[maiflai]

Then create a multi-module project and keep the legacy code and tests in the legacy project.

It simplifies keeping track of what is legacy and what is not.

[giovannicandido]

One use case is integrationTest with spring boot in JUnit which is better supported, and use scalatest for unitTest