-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstract over test frameworks using the SBT testing interface #951
Comments
Interesting... Does SBT testing interface (and the class graph utility) have cons? Reproducibility/Many dependencies/Runner performance? I'm just throwing stuff out there to better understand the trade off (or to understand there isn't a trade off 😄) Re migration- When you say a breaking change you mean that at the cut point we'll just drop the new experimental rule location but users who have been "conservative" and haven't done anything but just kept upgrading will continue to work (minus bugs), right? No API change or anything? |
Hey, folks. We've published a proposal to port some of the features from lucidsoftware/rules_scala, an alternative Scala ruleset that we maintain. Using the sbt test interface is one of them. Here's a link to the relevant proposal section that details specifically what we'd like to do, and a link to an issue we're using to track the broader effort: The tracking issue for this effort Are folks on board with our approach to solving this issue? We were hoping to take on this task in the near future. |
I'd like to abstract over test interfaces so that the
scala_test
rule supports all test frameworks implementing the SBT testing interface.This is relatively easy to implement using the SBT testing interface class graph utility and the new phase architecture. The new rule will then automatically discover any Scala test in the same way SBT discovers test.
The bigger issue is our migration strategy: I would like to replace the existing
scala_test
rule-- which only works for ScalaTest tests-- with this new generic rule. The Specs2 rules (scala_specs2_junit_test
, etc) can also be removed as the new rule will run Specs2 tests.One possible migration strategy is to introduce the new rule at a new location. During a cutover period the existing test rules can delegate to the new implementation. Once we are ready to make a breaking change, we can get rid of the old rules (just facades at this point) and rename/move the main rule over.
The text was updated successfully, but these errors were encountered: