Is there a way to run two separate test suites using it:testOnly with SBT?
I know that if I want to run one test suite I would use sbt "it:testOnly directory.testName", and that if I wanted to run a set of tests that all match a certain expression I could for example do sbt "it:testOnly directory.*", but I can't for the life of me figure out how to do two individual tests. I have tried
sbt "it:testOnly directory.test1 directory.test2"
and
sbt "it:testOnly directory.test1,directory.test2"
but neither of those work, and I can't find any documentation on it when I googled the issue.
Turns out I'd made a spelling mistake in the name of the second test. The correct format is
sbt "it:testOnly directory.test1 directory.test2"
Related
I want to run several sbt-commands within sbt interactive mode, i.e. without leaving the sbt "shell"?
(Note:
Some questions answer how to pass argument to sbt-commands using sbt in the standard shell. Not what I wnat here)
Example: I am in sbt interactive shell, and I want to run "test:compile", then "test"
I know test will call required compilation, but in this example I want to run the compilation of all sub-projects, before any test is started.
To run commands sequentially within the sbt shell, use ; to chain commands:
> ;test:compile ;test
Note however that running the test task will compile your sources if necessary without you having to explicitly running the compile task.
I currently have a command line sbt -Dsome.configuration.option test doing what I want, but I would like it to apply that configuration option automatically for sbt test (and no other sbt phase). If my terminology is correct, then I want to set a Java Option for the Test Configuration. How do I do this?
Searching on these terms has led me to http://www.scala-sbt.org/release/docs/Testing.html but I have not yet been able to understand it.
This question looks similar to mine: Define custom test configurations in sbt
Try this:
testOptions in Test +=
Tests.Setup(() => sys.props += "some.configuration.option" -> "true")
Caveat:
Because you're not forking this mutates the state of the system property in the JVM running sbt itself.
Which means that after running test the first time it that system property will also be set if you, for instance, run your main from within sbt (run/runMain).
A "simple" question: how can I automatically run PHPunit tests with Arcanist?
According to the documentation I should first load a custom library. As stated here I should create a .arcconfig file and load the appropriate library.
So: I've create a dir "arc_libs" in my project and in the dir "src" I used arc liberate to generate the needed files. My config is now:
{
"project.name" : "arc_libs",
"phabricator.uri" : "https://phabricator.xxx.xxx.net/",
"unit.engine" : "PhpunitTestEngine",
"load" : ["arc_libs/src"]
}
The libary DOES get loaded because I can run arc unit
[matthijs#xx xxx]$ arc unit
No tests to run.
But as you can see there are no tests to run. We keep our tests in "project_root/tests" and as far as I understand the documentation I should create a __tests__ dir in "the module" (probably my arc_libs dir ?)
However I want to run my existing PHPunit test files, not new tests I need to create. I tried using a symlink etc but I cannot get it to work. Arcanist doesn't detect my tests.
So my question: How can I automatically run my EXISTING PHPunit tests with arcanist?
(note we use arc diff that should run arc unit automatically)
The documentation you linked won't be very useful - it's aimed at Phabricator developers who want to test their libraries. There is some user-facing documentation for customising unit test tasks, but it's not great. Fortunately, it's quite easy to get Arcanist to run your project's unit tests using the included PhpunitTestEngine:
Prepare a phpunit.xml file in your project root. This should be a standard PHPUnit configuration file. You can test this by running phpunit -c phpunit.xml.
Add a phpunit_config option to your .arcconfig:
{
"phabricator.uri": "https://phabricator.xxx.xxx.net/",
"unit.engine": "PhpunitTestEngine",
"phpunit_config": "phpunit.xml"
}
Run arc unit to test it out.
Although user documentation is thin on the ground, the source code for PhpunitTestEngine has some comments and is fairly concise. If you run into problems, reading through the test engine code can help you track it down.
$ arc unit --help
unit [options] [paths]
unit [options] --rev [rev]
Supports: git, svn, hg
Run unit tests that cover specified paths. If no paths are specified,
unit tests covering all modified files will be run.
By default, arc lint and arc unit are meant to be used as part of a process of making changes, so by default it only acts on changed files. Odds are, you don't have any changed files. You probably want to specify some paths, or run arc unit --everything to run all tests.
I've run into a couple related cases with SBT that have me stumped. Is there a way to tell SBT to skip a sub project entirely for certain scala versions when you're cross compiling?
Here are two examples where this would be useful.
1) A build with three projects A, B, and C. Both A and B are scala projects, and have 'scalaVersions ++= Seq("2.11.2", "2.10.4") in their settings. Project C is a pure-Java artifact, and thus I've excluded the Scala libraries from it's dependencies. I'd like A and B to depend on C, but ideally I'd only like to build C just once. If I use the default behavior and do "+publish" from the root aggregator project, I get two copies of C-1.0.0.jar produced, and SBT attempts to publish it twice, which is of course a no-no for a maven repository.
2) A build with multiple scala projects, but where one project should only build against a single Scala version. I've tried defining 'scalaVersions' in the settings for this project to hold only one version where the other projects have two, but again "+publish" from a root aggregator seems to ignore this and still compiles it twice, with the second time failing because it's dependencies aren't available for that Scala version. This project is a leaf node in the dependency graph, so it's a perfectly fine thing to want to do logically.
For case #2, I've thought of setting the source dirs for the 'bad' scala version to /dev/null or something similar, but that still actually runs the build and produces an empty artifact. I know I could probably go in and find all of the relevant keys and do something like
publishArtifact := if(scalaBinaryVersion.value == "2.10") false else publishArtifact.value
and then hunt down all of the other related settings/tasks (compile, compile in Test, test in Test, packageBin, etc) but that seems pretty hack-ish. Is there a 'skip' setting somewhere?
I wrote sbt-doge to address task aggregation across subprojects respecting their crossScalaVersions. For Java projects you might need a dummy crossScalaVersion entry.
The plugin sbt-doge can be used to specify a crossScalaVersion setting in each subproject.
First, add the line addSbtPlugin("com.eed3si9n" % "sbt-doge" % "0.1.5") to your projects/plugins.sbt.
To avoid the ridiculous doge syntax ("such compile", really?) you need to enablePlugins(CrossPerProjectPlugin) in your root project. With this, you can add a plus sign before your sbt commands, and they will honor the cross build settings. Just like this: + compile.
sbt's test-only command can be used to run the tests found in a specific test class. With JUnit tests you can use test-only to run specific methods on a test class e.g. test-only mypackage.MyTestClass.test1Equals1 to run just that method.
Is such a thing possible with scalatest's more free-form test syntax, presumably by working out the name it uses internally to reference a specific test? If it isn't possible in FreeSpec (which is easy to imagine given its nature) is there a way to do it with a simpler testing approach like FunSuite?
For a general solution we need to wait for sbt#911, but apparently ScalaTest 2.1.3 has a support for running a specific test. Seth says:
This is now supported in ScalaTest 2.1.3 with:
test-only *MySuite -- -z foo
to run only the tests whose name includes the substring "foo". For exact match rather than substring, use -t instead of -z.
To run a test:
sbt test-only com.path.to.UnitTestSpec
To run a particular integration test:
sbt it:test-only com.path.to.IntegrationTestSpec