I have been working on the Maven plugin for ScalaTest, which was
started by Jon-Anders Teigen several years back and continued by Sean
Griffin more recently. I moved it here:
I changed the names of several of the parameters to be consistent with
the Ant task, and added a forkMode because of a user request.
Those of you using the old one, if you get a chance please upgrade to
this branch and let me know if all goes well.
One question I have is whether we need the gui goal that Jon
originally put in there, or are the test and report goal enough.
On Oct 19, 10:50 am, Bill Venners <b...@artima.com> wrote:
> Hi All,
> I have been working on theMavenplugin for ScalaTest, which was
Is Surefire integration via the JUnit XML output? Or are there other
ways tools integrate with it?
> You received this message because you are subscribed to the Google
> Groups "scalatest-users" group.
> To post to this group, send email to scalate...@googlegroups.com
> To unsubscribe from this group, send email to
> For more options, visit this group at
> ScalaTest itself, and documentation, is available here:
The 2 features in ScalaTest that save the day are its ability to run
its tests with JUnit (@RunWith(classOf[JUnitRunner]) I think is the
syntax) and its ability to output the test results as JUnit XML. The
surefire-report-plugin just cares about the JUnit XML and doesn't care
how it got there, and the CI servers/features I've used (Hudson/
Jenkins with a Maven project configuration) are the same way. Given
this fact, you can either stamp all your Scala tests with the @RunWith
annotation and continue to use surefire just like you do for any Java
project, or you can configure this separate maven-scalatest-plugin and
configure it to output JUnit XML. Either way should get you the
capabilities you're mentioning.
What this separate maven-scalatest-plugin can get you that direct
surefire cannot is the ability to do ScalaTest-specific things, like
including/excluding tags, producing other types of Reporter output,
and integrating the results of any Reporter into the Maven site. This
is especially important for projects that document their requirements
in BDD style and what those requirements included as part of the
project documentation in the site. These extra capabilities are
really the driving desire behind this plugin.
To be fair, implementing the Surefire Provider API would allow
Surefire's built-in execution modes to be applied to ScalaTest. In
particular, when I was looking at it originally I noticed that it may
enable forkMode logic to be inherited for free, and some projects need
that. But...it sounds like from prior posting that Bill has already
added a fork feature to the maven-scalatest-plugin, so that takes care
 Its ability to "just work" is debatable. It would if all tests
were Scala tests but Surefire doesn't like a mixture of different
providers in use, and the provider is chosen by what JARs are on the
classpath. At least this is how it works with the TestNG provider.
If you have both JUnit tests and TestNG tests then surefire gets
confused as to which provider it's supposed to use and only runs one
type. The only way to get around this is to separate into different
surefire runs with different test classpaths (junit in one, testng in
the other). I imagine a ScalaTest provider would suffer from the same
Yes, it's primarily XML. For example, TeamCity's XML test reporting
plugin reads Surefire reports, among others.
Tags could perhaps be shoehorned into Surefire's "groups" parameter
since they're essentially the same thing. Groups, along with a few
other options, was added to Surefire on behalf of TestNG. Perhaps the
same could be done for ScalaTest? :) I agree that a BDD capable
Reporter is the big win though.