I added the scoverage plugin to projects/plugins.sbt
addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.3.5")
I was able to generate test coverage using
sbt clean coverage test
sbt coveragereport
However when I try to add socverage config to my build.sbt. I see build errors
error: value ScoverageKeys is not a member of object scoverage.ScoverageSbtPlugin
ScoverageSbtPlugin.ScoverageKeys.coverageMinimum := 70
Looks like build.sbt does not find Scoverage classes. What is going on here?
check that out. Seems like what you need is:
scoverage.ScoverageKeys.coverageMinimum := 70
Related
I was wondering, is it possible to run scoverage from intellij (not from the terminal ) and even better, see scoverage reports like the native coverage from intellij?
Thanks
I've managed to collect coverage by adding scalac-scoverage-plugin as a test dependency:
libraryDependencies += "org.scoverage" %% "scalac-scoverage-plugin" % "1.4.0" % Test
I'm following the sbt directions here:
The instructions say to include this in my build.sbt file:
libraryDependencies += "org.apache.lucene" % "lucene-core" % "6.4.1"
But When I put that into IntelliJ, it gives the error: unresolved artifact. Not resolved or indexed. I'm new to Scala and SBT. Can someone help?
After you add library you need to refresh SBT project. you can move cursor to this error, and Option+Enter in mac or Alt+Enter in Windows/Linux for Refresh project. like:
I am trying to compile Scala project which contains scalatest.
It compiles normal on sbt
sbt
> compile
> test:compile
, but when I am trying to build it with IDEA, it shows the following error:
Error:(37, 11) exception during macro expansion:
java.lang.NoSuchMethodError: org.scalactic.BooleanMacro.genMacro(Lscala/reflect/api/Exprs$Expr;Ljava/lang/String;Lscala/reflect/api/Exprs$Expr;)Lscala/reflect/api/Exprs$Expr;
at org.scalatest.AssertionsMacro$.assert(AssertionsMacro.scala:34)
assert((ElementMeasures.baseElementDistance(mEl1, mEl2) - 0.33333).abs < 0.001)
^
for each assert function in test.
build.sbt file contains following:
name := "ner-scala"
organization := "ml.generall"
version := "1.0-SNAPSHOT"
scalaVersion := "2.11.8"
libraryDependencies += "org.scalactic" %% "scalactic" % "3.0.0"
libraryDependencies += "org.scalatest" %% "scalatest" % "3.0.0" % "test"
...
It may also mean that you have more than one versions of scalatest registered. I came into pretty same issue with compile-time error on assert
I just ran into the same problem and as Alexey described (he should get the upvote but I don't have enough reputation to upvote or comment - thank you Alexey), it seems that it was caused by having multiple versions of scalatest in my project. I was able to fix it by specifically excluding the older scalatest from the library that brought it in (and please note that the exclude needs to specify the scala binary version, e.g. _2.11 etc.!):
...exclude("org.scalatest", "scalatest_2.11")
There had also been a warning in the event log before the exclude:
SBT project import
[warn] Multiple dependencies with the same organization/name but different versions.
[warn] * org.scalatest:scalatest_2.11:(2.2.6, 3.0.1)
I think your IntelliJ is missing library scalatest
from IntelliJ, go to Project Structure -> Project Settings -> Libraries -> + symbol -> From Maven -> search for scalatest with correct version
after adding scalatest library for IntelliJ, assert error should disappear.
This is not a guaranteed solution, just give it a try :)
Sometimes, there are incompatibilities between how Intellij IDEA compiles scala, versus how sbt compiles scala. What you can try doing, is ask the IDEA to compile as sbt, and not as it does by default.
In the sbt view, you need to open the sbt settings.
Once it is opened you can enable the "builds" checkbox. As stated by IDEA, it is recomended for sbt build configurations that cause compilation nin IDEA to not work correctly.
Excluding just the org.scalatest group did not work for me. On analyzing my mvn dependencies I had to exclude the scalactic_{scala_binary_version} group as well.
<exclusion>
<artifactId>scalactic_2.11</artifactId>
<groupId>org.scalactic</groupId>
</exclusion>
I had a similar issue, but excluding org.scalatest did not fix it.
Instead, I excluded org.scalactic:
"com.stackoverflow" %% "troublesome-library" % "1.0.420" excludeAll(ExclusionRule(organization="org.scalactic"))
I am trying to add Scalding 2.10 as a managed dependency via build.sbt like so:
name := "ss"
version := "1.0"
libraryDependencies += "com.twitter" % "scalding_2.10" % "0.10.0"
IntelliJ downloads the jar and adds it as an external library (see screen below) but fails to resolve the com.twitter namespace.
I have tried both invalidating the IntelliJ cache and generating project files via sbt gen-idea but neither solutions have worked. Any ideas would be greatly appreciated.
The scalding jar file scalding_2.10 has no code in it to compile against. Its just 300 Bytes in size.
The correct dependency I feel should be
libraryDependencies += "com.twitter" % "scalding-core_2.10" % "0.11.1"
As the comment suggest try rm-ing your ivy2 cache, and try sbt gen-idea. If that doesn't work, other things to check:
makes sure you have indeed got the scala plugin installed.
Most likely you're java SDK is not set or pointing somewhere wrong; right click the project dir, click "Open Module Settings", go to SDK and make sure the path is correctly set to the jdk otherwise syntax highlighting will likely break.
To test your deps have been properly pulled in from tinternet, try sbt compile; if it compiles then you should indeed have downloaded the dependency properly.
As part of a CI setup the very first step is to create a package/jar using SBT dist. The following steps are to run unit, integration and functional tests with the dist-created jar.
Is it possible to do that with SBT?
Normally I use sbt testOnly "Unit.*", but that works in the context of a project. I can't find any documentation showing how to do this when there is already a jar.
I'm using ScalaTest and I know there is a runner for it I could use http://www.scalatest.org/user_guide/using_the_runner. But using SBT would be simpler, if that is possible.
As an example, something like this is what I am looking for:
sbt testOnly "Unit.* -jar myjar.jar"
Will my tests even be included in the jar when I use the following:
sbt dist
?
EDIT
I created a new folder
I added build.sbt with the following content:
name := "abc"
version := "1.0-SNAPSHOT"
scalaVersion := "2.10.0"
I added the lib folder and copied my tests jar into it
I ran sbt testOnly Unit.*
It could not find any tests
EDIT 2
I tried with the following "proper" SBT file:
name := "ihs2tests"
version := "1.0-SNAPSHOT"
scalaVersion := "2.10.0"
unmanagedBase in Test := new java.io.File(".")
and moved test.jar into the root of the project. Again, no tests found.
Normally I use sbt testOnly "Unit.*", but that works in the context of a project. I can't find any documentation showing how to do this when there is already a jar.
The test-family tasks in SBT (with testOnly as an example) work with compile task that returns a list of compiled files through an sbt.inc.Analysis instance. I couldn't figure out how to amend it and inject the changed Analysis instance to testOnly so it knows the test I'm going to run exists.
I'm proposing another solution - a trick.
Package the tests classes to a jar with test:package task as follows:
[test-lib]> test:package
[info] Updating {file:/Users/jacek/sandbox/so/test-lib/}test-lib...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Compiling 1 Scala source to /Users/jacek/sandbox/so/test-lib/target/scala-2.10/test-classes...
[info] Packaging /Users/jacek/sandbox/so/test-lib/target/scala-2.10/test-lib_2.10-0.1-SNAPSHOT-tests.jar ...
[info] Done packaging.
[success] Total time: 9 s, completed Mar 4, 2014 11:34:13 PM
When you have the test jar, you can execute the test framework on the command line without SBT (I assume you use ScalaTest given the scalatest tag, but I'll use Specs2). Read the documentation of the test framework on how to do it and for Specs2 it's specs2.run as described in Console output.
Executing tests from the test jar requires defining a proper CLASSPATH that may or may not be easy to get right. That's where SBT can be of great help - to manage dependencies and hence the CLASSPATH.
Create another SBT project and save the test jar in lib subdirectory to have it on CLASSPATH (as described in Unmanaged dependencies).
Dependencies in lib go on all the classpaths (for compile, test, run, and console).
Add a sample build.sbt where you define your test framework as a dependency of the project. For Specs2 it's as follows (I used the default configuration as described in the Specs2 home page):
libraryDependencies += "org.specs2" %% "specs2" % "2.3.8" % "test"
scalacOptions in Test ++= Seq("-Yrangepos")
The trick is to execute the main class of the test framework, e.g. specs2.run for Specs2, as if the class were executed on the command line. SBT helps with test:runMain.
[my-another-project]> test:runMain specs2.run HelloWorldSpec
[info] Running specs2.run HelloWorldSpec
HelloWorldSpec
The 'Hello world' string should
+ contain 11 characters
+ start with 'Hello'
+ end with 'world'
Total for specification HelloWorldSpec
Finished in 62 ms
3 examples, 0 failure, 0 error
Exception: sbt.TrapExitSecurityException thrown from the UncaughtExceptionHandler in thread "run-main-0"
[success] Total time: 5 s, completed Mar 4, 2014 11:15:14 PM
Don't worry about this Exception as it comes from SBT that catches exit from Specs2 (after test execution) so SBT remains up.
It seems that SBT can't read jar file without any additional/manual setup - I might be wrong but I didn't find anything in the docs. So I tried something like this to make the task simpler:
unzip some-test.jar
java -jar sbt-launch.jar \
'set scalaSource in Test := new java.io.File(".")' \
'set fullClasspath in Test += Attributed.blank(file("."))' \
'test'
This runs without errors but does not find tests.
If I add 'set includeFilter in (Test, unmanagedSources) := "*Suite*.class"' to force it to find tests it obviously fails because it expects *.scala files, not the compiled *.class files.
I'm not an SBT expert, but I think this must be close to a solution. There must be a way to read all files from a jar path programmatically and then tell test framework to use *.class files.
At this point is seems more reasonable to run tests using a Scalatest test runner or from sbt using the project.
If you wish to dig deeper take a look at SBT source code and the default sbt shell script that does lots of setup before it runs the sbt launcher jar.