Skip to content
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

Remove hardcoded references to ScalaTest and/or ScalaCheck #84

Open
frgomes opened this issue Jun 19, 2017 · 4 comments
Open

Remove hardcoded references to ScalaTest and/or ScalaCheck #84

frgomes opened this issue Jun 19, 2017 · 4 comments

Comments

@frgomes
Copy link
Contributor

frgomes commented Jun 19, 2017

I've noticed that TestGen contains

  def importArbitrary(examples: Seq[ParsedDoctest]): String =
    if (containsProperty(examples)) "import org.scalacheck.Arbitrary._" else ""

  def withCheckers(examples: Seq[ParsedDoctest]): String =
    if (containsProperty(examples)) "with org.scalatest.prop.Checkers" else ""

sbt-doctest should not assume that the user is always going to use ScalaTest + ScalaCheck.

I the case of ScalaJS, chances that the application developer is employing uTest both in the JVM side and JS side. So this issue seems to be related to #52

@frgomes frgomes changed the title Remove all hardcoded dependencies from ScalaTest and/or ScalaCheck Remove hardcoded references to ScalaTest and/or ScalaCheck Jun 19, 2017
@frgomes
Copy link
Contributor Author

frgomes commented Jul 1, 2017

@lloydmeta : The idea is that the user determines which test framework and which version of libraries the user needs. As far as I understand, ScalaTest changed the location of checkers and so, in this case, sbt-doctest must be prepared to provide these two flavours.

Ideally, sbt-doctest should not have any hardcoded stuff. However, for maximum convenience, we could refactor the harcoded stuff, keeping it in certain specific locations. Borrowing the example from #88, we could have something like this:

  1. Suppose that the user prefers ScalaTest 3.0.1. In this case, the user configures build.sbt more or less like this:
val scalaTestRunner = "doctest.runner.scalatest.v30.Framework"
val argsDocTest: Seq[String] = ...
val argsScalaTest: Seq[String] = ... // see: http://www.scalatest.org/user_guide/using_the_runner
val args = argsDocTest :: "--" :: argsScalaTest
...
val tf = new sbt.TestFramework(utestRunner)
testFrameworks ++= Seq(tf),
testOptions ++= Seq(Tests.Argument(tf, args)),
...

In this case, the class doctest.runner.scalatest.v30.Framework configures a certain setting which says that org.scalatest.prop.Checkers must be employed.

  1. On the other hand, if class doctest.runner.scalatest.v31.Framework is employed, it will configure a setting which says that org.scalatest.check.Checkers must be used instead.

Please let me know what you think. Suggestions are welcome! :-)

@tkawachi : your feedback, please.

@lloydmeta
Copy link

My only recommendation is that whatever solution is taken, that there be a reasonable default provided by this plugin that requires no additional configuration from the end user (e.g. add the this plugin and doctests "should work"). It could, for example that sbt-doctest works out of the box with Scalatest+Scalacheck for mindshare and legacy reasons, and the user can configure it to do otherwise, if they so wish.

@tkawachi
Copy link
Collaborator

tkawachi commented Jul 2, 2017

This plugin generates tests, but not run these. By seeing Framework.java, it seems not for a test generator.

I'm rather thinking to add ScalaTest31 as a subclass of DoctestTestFramework.

@tkawachi
Copy link
Collaborator

tkawachi commented Jul 2, 2017

withCheckers() is only used by ScalaTestGen. It is moved to ScalaTestGen at #92.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants