I have some long running tests in my project. These these are sitting in parallel to my integration and unit-tests in
/test/manual/*
Is there in Play 2.4 for Scala a way to disable/mark these test classes. So they are not run automaticly when
$ activator test
but only run when using the test-only command.
Problem is that I do not want to run these longer tests on my CI server.
Having similar problems for long-running integration tests, I created an It configuration derived from the standard test config (in <projectHome>/build.sbt):
lazy val It = config("it").extend(Test)
Then I add the sources and test sources to this config
scalaSource in It <<= (scalaSource in Test)
and you needd to enable to config and corresponding tasks available in the current project
lazy val root = (project in file(".")).configs(It)
.settings(inConfig(It)(Defaults.testTasks): _*)
I then disable long running tests in the Test config :
testOptions in Test := Seq(Tests.Argument("exclude", "LongRunning"))
And include only these long running tests in the It config:
testOptions in It := Seq(Tests.Argument("include", "LongRunning"))
These last 2 configs are kinda dependent on the test framework you use (specs2 in my case, scala test would probably use -n and -l in addition to tags to achieve the same)
Then sbt test will exclude all LongRunning tests and you can run it:test or it:testOnly your.long.running.TestCaseHere in an interactive sbt session if need be.
Related
I have a multi-project sbt build (each project is micro service).
For development convenience, I want to run all of them at the same time.
Is it possible with sbt?
lazy val root = (project in file("."))
.aggregate(
serviceA,
serviceB
)
lazy val serviceA = (project in file("service-a"))
...
lazy val serviceB = (project in file("service-b"))
...
I can run them individually with serviceA/run or serviceB/run
But I need to run serviceA and serviceB with single sbt command (they will be running on different ports)
You could try to use Ammonite
We us Ammonite scripts (e.g. runner.sc) to run sbt. I never used Future as we run one thing after the other.
Or use a simple bash file:
Your requirement is more or less running sbt in the background.
Here is an according question: how-to-run-sbt-as-daemon
Taking this to your question, this could look like:
#!/usr/bin/env bash
sbt -Djline.terminal=jline.UnsupportedTerminal serviceA/run &
sbt -Djline.terminal=jline.UnsupportedTerminal serviceB/run &
I couldn't test this, let me know if it works.
I have an sbt project for which I am writing integration tests. The integration test deploys the API defined in the project. I need the version of the project from sbt in order to deploy the corresponding version of the API which has been published to a remote repository (x.x.x-SNAPSHOT). After it is deployed, I'll run integration tests against it.
Is there a way to pass Keys from sbt to a unit test class? I'm using Scalatest and sbt 1.2.7
If you run your unit/integration tests in a forked JVM, you can pass the version through a system property to that JVM:
Test / fork := true
Test / javaOptions += s"-Dproject.version=${version.value}"
Change the scope according to how you set up your unit tests (you might need to use a different configuration or even a specific task).
If you don't want to run your tests in a forked JVM, you could use the following setting to set up the system property before running your tests:
Test / testOptions += Tests.Setup(() => sys.props += "project.version" -> version.value)
In either of these cases, you then should access the project.version system property in your tests to get the version number:
val version = sys.props("project.version")
Alternatively, you can generate a file and put it into your generated resources directory, and load the version number from there:
// build.sbt
Test / resourceGenerators += Def.task {
val versionFile = (Test / resourceManaged).value / "version.txt"
IO.write(versionFile, version.value)
Vector(versionFile)
}
// your test
val is = getClass.getClassLoader.getResourceAsStream("version.txt")
val version = try {
scala.io.Source.fromInputStream(is).mkString
} finally {
is.close()
}
To keep the question as short as possible I just need to know if there's a way to set fork to false directly from the command line when launching activator instead of hard coding it as follows "fork in Test := false" from under build.sbt in a play-framework 2.4 based project.
__________________All below is for further context___________________
I'm maintaining a "legacy" project based on play framework version 2.4, and been trying to configure my IntelliJ environment to enable debugging with unit tests. To achieve this I created 2 run configurations, the first launches activator in debug mode and pipes all its output to IntelliJ console, the second attaches the debugger to the formerly launched jvm. I'm then free to run and debug any tests as I please from activator's prompt.
In order for the debugger to work though, I have to add the following to my build.sbt:
fork in Test := false
which allows for debugging with my IntelliJ project setup, since I have it properly configured to take my "conf/test-config.conf" into consideration when launching activator. But when I simply run "activator test" from a native command line console, with the fork option set to false, activator ignores my test-config.conf file (obviously with configurations tuned for unit tests) and instead loads the original app config file "application.conf" causing my tests to fail with all sorts of conflicts. This happens even with the below configuration in my build.sbt:
javaOptions in Test += "-Dconfig.file=conf/test-application.conf"
Commenting out "fork in Test := false" fixes the problem when I launch the tests from a native console (the unit tests run properly), my IntelliJ launch configuration also succeeds to run the tests but the problem is it loses its ability to debug the code, which is actually the whole point in the first place.
Here's the command I'm currently using from IntelliJ to launch activator in debug mode:
java -Dactivator.home=<activator-home-path> -Xms1024m -Xmx1024m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=256m -Dsbt.override.build.repos=true -Dconfig.file=conf/test-application.conf -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9990 -jar <activator-jar-path>
Simply use the following command when using sbt:
sbt "set fork in Test := false" test
For activator, you can try the following:
Add this to your build.sbt:
fork in Test := Option(System.getProperty("fork")) match {
case Some("false") => false
case _ => true
}
And then sumply run the following command:
activator -Dfork=false test
I have a multi-module project and currently run tests during packaging by a task which reads -
val testALL = taskKey[Unit]("Test ALL Modules")
testALL := {
(test in Test in module_A).value
(test in Test in module_B).value
(test in Test in module_C).value
}
Now, I have consolidated all tests in each module into a single top-level ScalaTest Suite. So for each module want to only run this single top-level suite (named say "blah.moduleA.TestSuite" and so on). Have been trying to use testOnly and testFilter in my build.sbt to run just this single suite in each module but cant get the syntax right. Can someone please tell me how to do this?
testOnly is an InputKey[Unit]. You want to turn it in a Task[Unit] to be able to run it directly for a given test suite.
You can achieve this this way:
lazy val foo = taskKey[Unit]("...")
foo := (testOnly in Test).fullInput("hello").value
In sbt's documentation: Preapplying input in sbt
I want to have an additional battery of tests to run against a database in addition to the unit test battery that requires no IO. What's the best way to do this with specs2 and sbt?
One of the solutions would be to put them in a namespace and use sbt test-only command:
$ sbt
> test-only com.example.utils.*
There's also a notion of tags in Specs2, which could be used to include or exclude tests at run time via SBT configuration.