I have some tests that are annotated in their super class as needing the JUnitRunner but they are ignored unless the annotation is added to the test class itself.

This is just meant to be a duplicate of #35 but for SBT 1.3, and putting SBT 1.3 in the title of the issue to help anyone searching on the web for a solution.

I came across #35 while trying to understand why my JUnit tests stopped running when I moved from SBT 1.2.8 to 1.3.13 (both with junit-interface 0.11).

Basically the same crossPaths := false solution from #35 works in the case of SBT 1.3.

As far as I can tell, neither --include-categories= nor --include-categories= do anything. Given e.g.

@org.junit.experimental.categories.Category(com.example.FastTests.class)
public class ExampleTest {
  @org.junit.Test
  public void test() {
    ...
  }
}

...both test-only -- -v --include-categories=com.example.FastTests and test-only -- -v --exclude-categories=com.example.FastTests run all tests.

I have a project where we have lots of unit tests written. We've recently upgraded to sbt 0.13 and now our unit tests don't run. If I add the following to my build.sbt:

crossPaths := false

then it picks up the tests and runs successfully.

I built my own version of the plug-in and put in some debugging statements and then turned on global debugging within the build.sbt and it appears that the JUnitRunner is never even instantiated when crossPaths is defaulted to true.

This bug was originally filed with SBT and was tracked down to being an issue in junit-interface.

The -q option makes the SBT console disappear. I've created a repository that reproduces this bug.

The console prompt should reappear when the tests have finished running:

[success] Total time: 0 s, completed Oct 30, 2014 5:34:15 PM
>

However, due to this bug, often times you won't see the prompt appear after the tests have run:

[success] Total time: 0 s, completed Oct 30, 2014 5:41:37 PM

This is super annoying because it was happening to me nearly every time I run my tests making me constantly kill and restart the SBT console. It happens much less with the sample repository than my real project (I'm guessing because there are fewer tests so I hit whatever race condition less often). I added the -q option following a suggestion from @jroper on the Play mailing list and not really examining what the option does. When I try it now I find that I can see absolutely no difference in the output with the option on or off and so the option seems to be rather broken as it is having no effect.

@retronym suggested the following:

At a minimum, it would be good to detect when it is being used in a parallel test run and try to fail fast.

I suppose junit-interface could to install a custom OutputStream that multiplexes across a ThreadLocal[OutputStream]. The test started event could increment an AtomicInteger counter, test finished would decrement. When the counter goes from 0 -> 1, this multiplexing stream would be installed as System.out, conversely when it goes from 1 -> 0 the original could be restored.

Googling ThreadLocalOutputStream yields a similar approach taken in startup-java-fast.

Is there a road map to add JUnit 5 Compatibility.

I'm not even certain that this is a bug in junit-interface; please shoot me down if you feel this issue should be logged somewhere else.

I've got a handful of Play projects with specs2 tests that subclass SpecificationWithJUnit and have @RunWith annotations. In older versions of Play (depended on junit-interface 0.8) these tests executed as expected. With the latest version of Play (depends on junit-interface 0.9) I'm seeing all of my tests execute twice.

If I remove the @RunWith annotations, the problem goes away. Removing these annotations prevents our tests from being executable within Eclipse, though.

I can work around this by pulling in 0.10-M2 and using --ignore-runners=org.specs2.runner.JUnitRunner, but this feels like a hack. Do you consider the double test execution a regression in junit-interface, or a bug in Play?

@szeiger @jsuereth @pvlugter would love a new version to be released! we have 500+ junit tests in my project and have been wanting forever the junit category support that @jroper recently added

In Play we have a problem with Specs2 tests not being picked up by SBT. Whether tests pass or fail, SBT reports that no tests were run:

[info] Passed: Total 0, Failed 0, Errors 0, Passed 0
[success] Total time: 8 s, completed 22/10/2013 6:08:09 PM

I created a small SBT application, captured in this gist, that reproduces the problem. The problem occurs when all three of the following are present:

• tests are forked
• the specs2 test has @RunWith(classOf[JUnitRunner])
• the JUnit interface is given the argument --ignore-runners=org.specs2.runner.JUnitRunner

We can work around the problem by changing the order of testFrameworks so that Specs2 runs before JUnit. This is our solution for now.

But this solution is fragile and it would be great to fix the underlying problem. I've talked with @harrah, and he thinks that the underlying issue is in junit-interface, probably the same issue as reported in #21.

junit-interface 0.11 was released over 6 years ago. Since then, various improvements have been pushed to this repo including 2018357 last year which provides some nice improvements to the test output. Would it be possible to publish a new release to maven?

Hi,

I am using sbt + spring + junit-interface.
I have an issue with @ContextConfiguration, it desn't load configuration file automatically.

Snippet from the Spring documentation:

package com.example;

@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from "classpath:/com/example/MyTest-context.xml"
@ContextConfiguration
public class MyTest {
    // class body...
}

Instead of automatically loaded ApplicationContext I get FileNotFoundException:

...nested exception is java.io.FileNotFoundException: class path resource [com/test/app/AppTest-context.xml] cannot be opened because it does not exist

The test class and configuration file is located in the same directory e.g., AppTest.scala and AppTest-context.xml

Adding full path to configuration file solve the problem

@RunWith(classOf[SpringJUnit4ClassRunner])
@ContextConfiguration(Array("file:src/test/scala/com/test/app/AppTest-context.xml"))

Is this junit-interface issue?

Best,
Krzysiek
@kgrodzicki

As discussed in https://groups.google.com/forum/#!topic/sbt-dev/acLAoKATsD4 would you like to move this project to the sbt organization. It would be easier to perform maintenance.
Thanks

related to the test reporting that was implemented for #48

I see a lot of these reported in Jenkins where my specs2 tests are reported by the junit reporter

<testcase classname="xx.xxx.FooSpec" name="(It is not a test)" time="-0.001"></testcase>

So the reporting is not skipping files that are not JUnit test files

When assertThat statement fails, the stack trace always shows "at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)".
I'd like it to show "com.shinichy.convertBox.test.MainActivityTest.checkViews(MainActivityTest.scala:41)" line.

The stack trace is below.

org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
org.junit.Assert.assertThat(Assert.java:865)
com.shinichy.convertBox.test.MainActivityTest.checkViews(MainActivityTest.scala:41)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
...

I confirmed this on JUnit 4.11 + junit-interface 0.9.

This is what is reported in the junit xml reports

sbt.ForkMain$ForkError
    at com.xxx.ServerTest.testInjectingRawData(ServerTest.java:573)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

But the actual failing test stacktrace looks like this

[error] Test com.xxx.ServerTest.testInjectingRawData failed: java.lang.NullPointerException: null, took 0.118 sec
[error]     at com.xxx.ServerTest.testInjectingRawData(ServerTest.java:573)
[error]     ...

On Windows, if you open a file handle, you can never modify / delete / move that file until the file handle is given up.

Unfortunately, the java.util.jar.JarFile API is a big offender and creates a file handle on creation. It only gives up the handle if close() is called directly or via finalize().

If sbt is set up to use exportJars, and junit-interface is used (I've confirmed and isolated that the junit-interface must be present to trigger this bug), JarFile references are not closed and - for some inexplicable reason - forcing gc and runFinalizers doesn't trigger the finalizers to run (this is a well known "feature" of Java), as per sbt/sbt#1223 which seems to workaround similar bugs in the scala compiler itself, see https://issues.scala-lang.org/browse/SI-9632 and https://github.com/ensime/ensime-server/issues/1322 (I'll give this an SI- soon).

Unfortunately, this is quite a serious bug.

It has the unfortunate side effect that the build tool can no longer delete any of the jars and compilation effectively becomes a no-op. I believe sbt may silently fail at this point, but I'm using some extremely loud customisations that check for failure https://github.com/fommil/sbt-big-project/blob/master/src/main/scala/BigProjectSettings.scala#L104

Others may have experienced this but it would have manifested itself in terms of the jar file not being updated.

In case it is relevant (I'm not sure it is), my project uses junit 4.11.0 and I depend on junit-interface intransitively.

It would be nice to see the reason for ignored test (if it's set) in EventDispatcher.testIgnored.

At the moment, https://github.com/sbt/junit-interface/blob/master/src/main/java/com/novocode/junit/JUnitRunner.java#L123 loads all the test classes in the same classloader.
Depending on the amount of tests, this becomes a problem, because class definitions get loaded multiple times, but are not garbage collected.

At my current project, this leads to Out of memory: Metaspace exceptions after a few tests.

I think it would be good if we could create a child classloader for every TestClass which we throw away after the tests ran.

What do you think?

build.sbt libraryDependencies

  "com.novocode" %% "junit-interface" % "0.11" % "test"

[error] (*:update) sbt.ResolveException: unresolved dependency: com.novocode#junit-interface_2.11;0.11: not found

The suite runner should be exempt from RunWith support to prevent tests in suites from running multiple times.

i have a junit test called 'CachingSalesforceConnectionProviderImplTest', it is not recognized as a test

My build.sbt specifies the junit plugin:

libraryDependencies in ThisBuild += "com.novocode" % "junit-interface" % "0.10-M4" % "test"

The project has plenty of Java junit tests in the default {proj}/src/test/java that run fine when I use my Maven build.

Why would SBT not see my junit tests? Is there any way I can debug this?

The output I get:

[info] Loading global plugins from /home/devuser/.sbt/0.13.0-Beta2/plugins
[info] Set current project to myproj (in build file:/home/devuser/src/myproj/)
[info] Passed: Total 0, Failed 0, Errors 0, Passed 0, Skipped 0
[info] No tests to run for myproj/test:test
[info] Passed: Total 0, Failed 0, Errors 0, Passed 0, Skipped 0
[info] No tests to run for myproj-subproja/test:test
[info] Passed: Total 0, Failed 0, Errors 0, Passed 0, Skipped 0
[info] No tests to run for myproj-subprojb/test:test
[info] Passed: Total 0, Failed 0, Errors 0, Passed 0, Skipped 0
[info] No tests to run for myproj-subprojc/test:test
[success] Total time: 0 s, completed Jun 23, 2013 8:01:41 AM

Hi,

I'm using this to write my junit4 tests.
The test files are in src/test/java/.... but when I run "sbt test" I get "No tests to run for test:test".

How do I let sbt know that these tests exist?

Thanks!

I'm trying to run a test suite in Play Framework. I've upgraded Play locally to use junit-interface 0.10-M1, but @RunWith is still having no effect. I would expect my println to be visible on the console when running the tests.

package com.benmccann;

import junit.framework.TestSuite;

import org.junit.runner.RunWith;
import org.junit.runners.AllTests;

@RunWith(AllTests.class)
public class AllTestsSuite {

  public static junit.framework.Test suite() {
System.out.println("\n\nWHY ISN'T THIS METHOD BEING CALLED?\n\n");
    return new TestSuite();
  }

}

I have a rather big Scala project with JUnit tests written in Scala which I used to build with Maven but I thought I would give SBT a trie. Sadly the JUnit interface doesn't seem to find any of the more involved tests in the src/test/scala folder. Even though they are compiled properly. I thought it could have something to do with the fact that I use the @BeforeClass annotation in the companion object of the individual tests.

I couldn't reproduce the exact problem with a minimal example. In the example I came up with sbt seems to generate a random number X for the line.

[info] Passed: : Total X, Failed 0, Errors 0, Passed X, Skipped 0

Even though all tests produce output.

Here's the setup and output:

./build.sbt

name := "sbt junit test project"

version := "1.0"

scalaVersion := "2.9.1"

libraryDependencies += "com.novocode" % "junit-interface" % "0.8" % "test"

./src/test/scala/Test1.scala

import org.junit.Test
class Test1 {
  @Test
  def test1 {
    println ("Test1.test1 is here!")
  }
}

./src/test/scala/Test2.scala

import org.junit.Test
import org.junit.BeforeClass
object Test2 {
  var x = 0
  @BeforeClass 
  def setUp {
    x = 42
  }
}
class Test2 {
  @Test
  def test2 {
    println ("Test2.test2 is here!")
  }
}

./src/test/scala/org/bla/blub/Test3.scala

package org.bla.blub
import org.junit.Test
import org.junit.BeforeClass
object Test3 {
  var x = 0
  @BeforeClass 
  def setUp {
    x = 42
  }
}
class Test3 {
  @Test
  def test3 {
    println ("Test3.test3 is here!")
  }
}

And here is the output sbt produces when running test

$ sbt
[info] Set current project to sbt junit test project (in build file:/Users/bnord/tests/sbttest/)
> test
[info] Updating {file:/Users/bnord/tests/sbttest/}default-e153b9...
[info] Resolving org.scala-lang#scala-library;2.9.1 ...
[info] Resolving com.novocode#junit-interface;0.8 ...
[info] Resolving junit#junit;4.8.2 ...
[info] Resolving org.scala-tools.testing#test-interface;0.5 ...
[info] Done updating.
Test3.test3 is here!
Test2.test2 is here!
Test1.test1 is here!
[info] Passed: : Total 3, Failed 0, Errors 0, Passed 3, Skipped 0
[success] Total time: 1 s, completed 22.02.2012 11:34:15
> test
Test1.test1 is here!
Test3.test3 is here!
Test2.test2 is here!
[info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0
[success] Total time: 0 s, completed 22.02.2012 11:34:17
> test
Test3.test3 is here!
Test1.test1 is here!
Test2.test2 is here!
[info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0
[success] Total time: 0 s, completed 22.02.2012 11:34:19
> test
Test1.test1 is here!
Test2.test2 is here!
Test3.test3 is here!
[info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0
[success] Total time: 0 s, completed 22.02.2012 11:34:20
> test
Test3.test3 is here!
Test2.test2 is here!
Test1.test1 is here!
[info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0
[success] Total time: 0 s, completed 22.02.2012 11:34:21
> test
Test3.test3 is here!
Test2.test2 is here!
Test1.test1 is here!
[info] Passed: : Total 1, Failed 0, Errors 0, Passed 1, Skipped 0
[success] Total time: 0 s, completed 22.02.2012 11:34:23
> test
Test3.test3 is here!
Test1.test1 is here!
Test2.test2 is here!
[info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0
[success] Total time: 0 s, completed 22.02.2012 11:34:27

I'm trying to use cucumber-jvm with SBT, and it would be great if this tool could support @RunWith

package cucumber.examples.scalacalculator

import org.junit.runner.RunWith
import org.junit.Test
import cucumber.junit.Cucumber

@RunWith(classOf[Cucumber])
class RunCukesTest {

}

only is detected if you annotate it with @test above @RunWith - but then it doesn't return correctly after executing the Cucumber tests.

I found an issue when running a JUnit Parameterized and some newline content then junit-interface forgets how to count.

See: https://gist.github.com/dwijnand/e8764c519ae7d82ec147/4ee29e7f3e549e9134f7eb87f1f139a36cea4f6d

Right now, it just lists the class that had a failing test eventhough there are several tests in that class. It would be much more helpful if it listed the failed method names as well.

[error] Failed: Total 293, Failed 1, Errors 0, Passed 280, Skipped 12
[error] Failed tests:
[error]         com.connectifier.MyTest

This is the built-in, default summary from sbt. It is a generic summary that supports all frameworks and thus doesn't try to be too fancy. In the new test interface supported by 0.13, test frameworks can provide their own summary that will override sbt's.

https://github.com/sbt/test-interface/blob/master/src/main/java/sbt/testing/Runner.java#L87

I have a Java project that I'm building with SBT. The only Scala code is in the tests.
I need to run some slow tests in a separate process, with a high memory option (-Xmx).
I want to do that using forking. However, this does not work, as JUnit tests are ignored.

This is an excerpt of my build.sbt:

crossPaths := false
scalaVersion := "2.12.4"
autoScalaLibrary := false
sbtVersion := "1.1.1"
libraryDependencies += "org.scalatest" %% "scalatest" % "3.0.3" % "test"
libraryDependencies += "org.scalacheck" %% "scalacheck" % "1.13.5" % "test"
libraryDependencies += "junit" % "junit" % "4.12" % "test"
libraryDependencies += "com.novocode" % "junit-interface" % "0.11" % "test"
testOptions += Tests.Argument(TestFrameworks.JUnit, "-q")
Test / parallelExecution := false

This configuration makes my jUnit tests run when I do sbt test.
If I add fork in Test := true, then only my ScalaTest tests execute.

Version: 0.10-M4
Options passed in: testOptions += Tests.Argument(TestFrameworks.JUnit, "-v", "-s")

Reproducible by:

package test

import org.junit.Assert._
import org.junit.{ Test => T}

class Foo should be {
val isCool = false
@t def cool { assert(isCool) }
@t def nonEmpty { assert(true) }
@t def badass { assert(false) }
@t def hakker { assert(true) }
}

Output:

[info] Test test.Foo should be.nonEmpty started
[info] Test test.Foo should be.cool started
[error] Test test.Foo should be.cool failed: assertion failed
[info] Test test.Foo should be.hakker started
[info] Test test.Foo should be.badass started
[error] Test test.Foo should be.badass failed: assertion failed
[info] Test run finished: 2 failed, 0 ignored, 4 total, 0.008s
[error] Failed: : Total 4, Failed 2, Errors 0, Passed 2, Skipped 0
[error] Failed tests:
[error] test.Foo$u0020should$u0020be <<----------------- OFFENDING LINE
[trace] Stack trace suppressed: run last test:test for the full output.
error Tests unsuccessful
[error] Total time: 1 s, completed Jul 3, 2013 2:10:00 AM

Shouldn't this be Status.Ignored instead of Status.Skipped in EventDispatcher.java? I'm not really sure when you'd report a test as skipped, but I'd imagine if you mark a test with @Ignore then it should be reported as ignored instead of skipped given that a Status exists for both of those

@Override
public void testIgnored(Description desc)
{
  postIfFirst(new InfoEvent(desc, Status.Skipped) {
    void logTo(RichLogger logger) {
      logger.info("Test "+ansiName+" ignored");
    }
  });
}

That would be very usefull when projects are build by a CI server.

I would suggests using the same parameters as scalatest:

testOptions += Tests.Argument(TestFrameworks.ScalaTest, "-u", "target/scalatest-reports")

Please release 0.10 final as 0.10-M4 has been out there for 3 months.

Thanks.

Currently any non-option parameter is treated as a glob pattern which can lead to surprising bugs. For example, see https://gist.github.com/ktoso/baba2cacad58bddd4235 which is caused by "testOptions in Test += Tests.Argument("-oDF")" (parameters for ScalaTest which are not scoped correctly). Since glob patterns starting with a dash should be rare, I suggest we require an extra "--" separator before any such options, e.g. "test-only -- -v -a -- -reallyAPattern". Any other argument starting with a dash before this separator should be reported as an error and fail the whole test run.

Hi,

I am trying to use parallel test execution jenkins plugin with sbt but unable to do grouping of test cases

do we have any way of achieving it?

Junit 4.11 is out. Please update the 0.11 dependency.

Would be nice to have ability to add more than one run listener

I have two unit test classes in https://github.com/fommil/class-monkey but only one of them is run by sbt test.

This test is not picked up:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:test-context.xml"})
public class MyTest {

but if @RunWith is commented out the test is picked up (but obviously does not work correctly)

//@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:test-context.xml"})
public class MyTest {

This is using 0.11 of junit-interface library
libraryDependencies += "com.novocode" % "junit-interface" % "0.+" % "test"
...
Resolving com.novocode#junit-interface;0.11-RC1

The specs2 SBT test runner allows running individual specs:

sbt/sbt#911

junit-interface could likewise provide support for running individual test methods.

Cucumber tests with Data Tables will pass with failing examples as long as the first example passes.

This happens because all the examples have the same fully qualified name that comes from the scenario outline description.

I have submitted a PR to fix this #83 .

I have a project with a dependency on Spring Batch Test 4.1.0-RELEASE, which brings in Spring Test 5.1.2-RELEASE with it.

If I include junit-interface on the classpath, and plain dependencies (no exclusions) then ./sbt test gives:

[debug] Test run started
[debug] Test run finished: 0 failed, 0 ignored, 0 total, 0.001s

I have tried updated the dependencies to exclude JUnit 4.12, as follows:

libraryDependencies += "com.novocode" % "junit-interface" % "0.11" % "test"
libraryDependencies += "org.springframework.batch" % "spring-batch-test" % "4.1.0.RELEASE" % "test" exclude("junit", "junit")

This gives the following from ./sbt test:

[debug] Running TaskDef(LoadInternalUsersTests, com.novocode.junit.RunWithFingerprint@310e1f40, false, [SuiteSelector])
...snip...
[error] Test LoadInternalUsersTests.initializationError failed: java.lang.ExceptionInInitializerError: null, took 0.004 sec
[error] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[error] ...
[error] Caused by: java.lang.IllegalStateException: SpringJUnit4ClassRunner requires JUnit 4.12 or higher.
[error] at org.springframework.util.Assert.state(Assert.java:73)
[error] at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.(SpringJUnit4ClassRunner.java:104)

In SpringJUnit4ClassRunner.java there is a note saying "As of Spring Framework 4.3, this class requires JUnit 4.12 or higher".

Is there a reason why junit-interface won't run the tests when JUnit 4.12 is on the classpath and 4.11 is evicted?

The test failure messages are very frustrating because they don't include line numbers:

[error] Test com.benmccann.StringUtilTest.myTest failed: null
[info] com.benmccann.StringUtilTest
[info] x myTest

That makes it impossible to tell which line of this test failed:

@Test
public void myTest() throws Exception {
  Assert.assertTrue(MyClass.doSomething(1));
  Assert.assertTrue(MyClass.doSomething(2));
  Assert.assertTrue(MyClass.doSomething(3));
  Assert.assertTrue(MyClass.doSomething(4));
}

When a test fails due to an exception, junit-interface swallows the exception type, which makes debugging much more difficult.

@szeiger i know you've been a bit busy and have had a hard time keeping up with some of the issues and pull requests. Perhaps you could add another maintainer to the project to help reduce the burden? There's a chance someone creates a fork of this project if that's the only way to get fixes into it and I think that forks aren't a great situation for anyone since they cause lots of confusion. Perhaps @backuitist or someone at Typesafe would be interested in helping out?

Updating the build.properties to sbt.version=0.13.13 and running scripted shows that the categories suite fails. I ran into this because I was having a problem getting JUnit tests to run when using sbt on a java project - so far I've only seen it affect tests written in Java.

I'm planning to look into this and open a pull request (assuming I can fix the problem), but I was curious whether anyone here knows something that might have changed in 0.13.13 which would cause this breakage?

The error messages are quite unhelpful if -a is not set. This has caused me countless hours of frustration before I realized the option existed.

When you have output like the following, it's impossible to figure out what line the test is failing on when it's a large file with multiple assertions. All we get is "failed: null" and no line number or stacktrace, which was a recurring source of annoyance for the developers on our team.

$ ./activator test
[info] Loading project definition from /home/bmccann/src/play-java/project
[info] Set current project to play-java (in build file:/home/bmccann/src/play-java/)
[error] Test ApplicationTest.simpleCheck failed: null, took 0.02 sec
[error] Failed: Total 3, Failed 1, Errors 0, Passed 2
[error] Failed tests:
[error]     ApplicationTest
[error] (test:test) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 5 s, completed Nov 20, 2014 10:16:48 PM

There have been lots of fixes and changes recently. It would be great to test sbt & play with the latest code and release an RC

Counter-inutitively, --tests="foo" does not work as expected, it must be --tests=foo (no ").

This always catches me out.

Project that simulates the problem:

https://github.com/nraychaudhuri/junit_interface_ignore_runners_bug

Here is the summary:

I have one junit and one specs test with @RunWith annotation. If you run "sbt test" by commenting out the following line, it will run junit test and specs test twice

testOptions in Test += Tests.Argument("junitxml", "console", "--ignore-runners=org.specs2.runner.JUnitRunner")

Now add the line back to fix the @RunWith issue. But now junit tests will not run anymore.