ScalaTest Maven plugin update
Bill Venners
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:
https://scalatest.googlecode.com/svn/branches/maven-scalatest-plugin
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.
Thanks.
Bill
----
Bill Venners
Artima, Inc.
http://www.artima.com
Jonathan
to integrate with Surefire as opposed to replacing it. Surefire test
results are integrated with various other tools including continuous
integration servers. If it's possible to somehow make it work, that
would be the preferred approach.
- jonathan
On Oct 19, 10:50 am, Bill Venners <b...@artima.com> wrote:
> Hi All,
>
> I have been working on theMavenplugin for ScalaTest, which was
Bill Venners
Is Surefire integration via the JUnit XML output? Or are there other
ways tools integrate with it?
Bill
> --
> 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
> scalatest-use...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/scalatest-users?hl=en
> ScalaTest itself, and documentation, is available here:
> http://www.artima.com/scalatest
--
Sean Griffin
I think both approaches may have their place, though implementing the
Surefire Provider API may not provide enough value to justify the
development effort. Creating ScalaTest as a first-class Surefire
provider has the potential benefit that things "just work" [1].
Surefire and any tooling that consumes its API would integrate
perfectly. Unfortunately there are a couple of road blocks. First,
the Surefire Provider API, as with most other Maven APIs, is poorly
documented. You basically have to just look at existing providers as
an example and port the code. Second, the Surefire Provider API
requires separating the test discovery from the test execution; you
have to implement methods that return the number of tests you're going
to run, how many were ran, etc. Last I checked (~5 months ago)
ScalaTest coupled the test discovery to the test execution together in
the Runner class. Certainly this can be refactored, but as I'm about
to explain, this may not be worth it.
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
of that.
[1] 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
problem.
Jonathan
Yes, it's primarily XML. For example, TeamCity's XML test reporting
plugin reads Surefire reports, among others.
jonathan
Jonathan
since Surefire style output is produced.
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.
jonathan