Add specs2 support

[mvaitkus]

Adding two rules to run specs2 tests:

• scala_specs2_test for running standalone specs2 tests
• scala_specs2_junit_test uses junit runner for test execution

Junit xml output is not yet supported.

Rules tested in:
https://github.com/mvaitkus/bazel_scala_sample

[bazel-io]

Can one of the admins verify this patch?

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[ittaiz]

@johnynek they're Wix employees, they should be covered by the Wix organizational CLA right? cc @damienmg

[damienmg]

CLA bot got it wrong again.

[mvaitkus]

There are some things we are not sure about.

Currently in order to use the new rules, you need to add following lines to project WORKSPACE file:
load("@io_bazel_rules_scala//specs2:specs2.bzl", "specs2")
specs2()
Executing it will load specs2 dependencies to workspace using native.maven_jar(... so they can be accessed later in rules. We assume it is possible to somehow load them in scala_repositories method and would most likely not be downloaded if specs2 rules are not used, but we where not sure if it is good idea to pollute workspace with unused labels.

Another thing we'd appreciate feedback on is how we produce a list of test classes from the jar (we use jar tf command on the output jar to do this and then grep | sed | xarg run). Wondering if there's a better way to do this using bazel/skylark instead of using this bash.

Do you have any recommendations on xml output?
What we could think of - write a custom runner(s) with junit/specs event listeners. The runner(s) could probably also handle the tests to run list instead of bash command.

[ittaiz]

👍🏽 thanks!
On יום ה׳, 1 בספט׳ 2016 at 17:05 Damien Martin-Guillerez <
notifications@github.com> wrote:

CLA bot got it wrong again.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#88 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF_fHiVo8vHKzXsTsuq7wMUBuUFj3ks5qltu3gaJpZM4Jyqy-
.

[johnynek]

Sorry for the delay. I've been on vacation. Will look tomorrow. Thanks for
the contribution.
On Thu, Sep 1, 2016 at 05:34 Marius Vaitkus notifications@github.com
wrote:

There are some things we are not sure about.

Currently in order to use the new rules, you need to add following lines
to project WORKSPACE file:
load("@io_bazel_rules_scala//specs2:specs2.bzl", "specs2")
specs2()
Executing it will load specs2 dependencies to workspace using
native.maven_jar(... so they can be accessed later in rules. We assume it
is possible to somehow load them in scala_repositories method and would
most likely not be downloaded if specs2 rules are not used, but we where
not sure if it is good idea to pollute workspace with unused labels.

Another thing we'd appreciate feedback on is how we produce a list of test
classes from the jar (we use jar tf command on the output jar to do this
and then grep | sed | xarg run). Wondering if there's a better way to do
this using bazel/skylark instead of using this bash.

Do you have any recommendations on xml output?
What we could think of - write a custom runner(s) with junit/specs event
listeners. The runner(s) could probably also handle the tests to run list
instead of bash command.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#88 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEJdnC2p8rxVumEKjUmqMo878VINkg-ks5qltx_gaJpZM4Jyqy-
.

[johnynek]

this is already in the @scala target. Can we not use that one?

[johnynek]

can we add tests here?

One thing I am concerned about is that the dependencies of specs2 are a bit heavier. So, there is a decent chance a user is going to already have some of these dependencies in their tree. How can we deal with that?

I think that we need to move to using bind so that people can bind their own versions of things like scalaz. We can punt on that here, but at least we should not duplicate the scala artifacts that are in the scala-sdk tarball we fetch.

[johnynek]

maybe we can just have a junit target, and then in a macro, etc... have junit + specs. Some might just want to run a junit test without any specs.

[johnynek]

and/or the target can be a bind variable, and the users can set up what to point to.

[johnynek]

@ittaiz great to meet you and chat with you today!

[ittaiz]

decided to implement it a bit differently in the end. I implemented JUnit support and added specs2 on top of that (requires usage of SpecWithJUnit).
Additionally I made JUnit support imitate the maven behavior of discovery of test classes by using regexes on class names. see #163 for more info.

[mvaitkus]

Given that @ittaiz found a way to run specs2 on top of junit, I am closing this PR as no longer relevant.