When I execute sbt testOnly *JoinTest* no tests are found and the following output is shown, but com.typesafe.slick.testkit.tests.JoinTest should have been executed:
testOnly *JoinTest*
[info] Compiling 1 Scala source to /ext/git/slick/slick-testkit/target/scala-2.10/test-classes...
[info] Passed: Total 0, Failed 0, Errors 0, Passed 0
[info] No tests to run for testkit/test:testOnly
You're so close. Try this instead:
testOnly -- *JoinTest*
The -- allows you test send arguments to the test kit. Without that it's expecting a list of JUnit tests. More info here.
every time when I had a class called as yours .JoinTest to lunch / run all the tests from it I just wrote:
testOnly *.JoinTest
link from sbt 0.13 with details about this
additional if you want to run a specific test case from that class you can use the following command
testOnly *.JoinTest -- -z "test name you want to run"
to discover other commands that you can use with -- you can take a look at this link
Related
I setup the simple ZIO App from zio.dev.
val myAppLogic =
for {
_ <- putStrLn("Hello! What is your name?")
name <- getStrLn
_ <- putStrLn(s"Hello, ${name}, welcome to ZIO!")
} yield ()
When running in/with Intellij it works as expected.
However running it with mill it doesn't.
nbszmbp012:zio-scala-camunda-bot mpa$ mill server.run
[27/37] server.compile
[info] Compiling 1 Scala source to /Users/mpa/dev/Github/pme123/zio-scala-camunda-bot/out/server/compile/dest/classes ...
[info] Done compiling.
[37/37] server.run
Hello! What is your name?
Peter
name <- getStrLn is not executed.
Here is the build.sc
import mill._, scalalib._
object server extends ScalaModule {
def scalaVersion = "2.12.8"
def ivyDeps = Agg(
ivy"dev.zio::zio:1.0.0-RC10-1",
ivy"com.bot4s::telegram-core:4.3.0-RC1"
)
}
Did I miss something?
Mill runs, by default, in client-server mode. One of the consequences is, that build tasks can't consume the input stream.
Your given example needs to read from the process standard input. So, you have to explicitly tell mill to run in interactive mode with --interactive (or short -i).
$ mill -i server.run
[27/37] server.compile
[info] Compiling 1 Scala source to /tmp/zio-q/out/server/compile/dest/classes ...
[info] Done compiling.
[37/37] server.run
Hello! What is your name?
Peter
Hello, Peter, welcome to ZIO!
When invoked with the additional -i (before the task name), the ZIO app correctly reads from STDIN and prints the greeting.
No matter what I put in BUILD_LOG_EXCERPT, all I get is an email with an empty body, thus could use some assistance.
I have a java program that writes to console. Snippet of Jenkins console output looks like this:
...
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building project1 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- exec-maven-plugin:1.4.0:java (default-cli) # project1 ---
Parameters provided: SG, 100, 1000
query: select COUNT(*) from table1 where col1 = ? and col2 = ? and col3 = ?
Rows in table: 5776
Threshold: 100
Rows returned above threshold, skipping dpan generation batch file.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.125 s
[INFO] Finished at: 2016-02-08T09:31:37-08:00
[INFO] Final Memory: 8M/245M
...
In the Jenkins job, I create a Post Build step, and put the following line in Default Content:
${BUILD_LOG_EXCERPT, start="\\b(Parameters)\\b", end="\\b(Threshold)\\b"}
When I trigger the job, all i get is an empty email. However if I add
${BUILD_LOG, maxLines=9999, escapeHtml=false}
then i get the full console output in the email. Any ideas? I am using version 2.40.3 of the plugin.
Looks like your regex is failing to find any matches, so you aren't getting any lines of the log. This is because the BUILD_LOG_EXCERPT variable uses java.util.regex.Pattern.Matcher.matches() to match a regex - and this will only return True if the entire string matches (referenced in this SO question). The log parser is running line-by-line, so it's testing your entire line against your regex and failing (since there are characters after "Parameters").
If you're looking for a string that starts with Parameters but may have characters after it, you can match to
"\\b(Parameters)\\b(?s).*"
which will match "Parameters" and any arbitrary string after it.
BUILD_LOG_EXCERPT in email-ext follows a very simple regex match using start and end. got it working by using two echo statements i.e one at the start from where i wanted the piece of console log and one at the end position of the log you wanted in email.
example :
In Build step :
echo Start
<your build commands>
echo End
In Default section of email-ext use the below line to get it working :
${BUILD_LOG_EXCERPT, start="^Start", end="^End"}
if your using a html email output you can use below line to align output in email
<pre>${BUILD_LOG_EXCERPT, start="^Start", end="^End"}</pre>
you can tweak and get it working , Hope it works for you as it did for me .
I have a subproject named oppenheimer in my project. It's very simple to run this project from the sbt console.
[myproject] $ oppenheimer/run
I can also pass in a command line argument as such:
[myproject] $ oppenheimer/run migrate
[myproject] $ oppenheimer/run clean
How can I do this from build.sbt? Is it possible to define a task that does this? It would suffice to have something like this:
val customMigrate = ...
val customClean = ...
And this is so that I could use it elsewhere in the project, like such:
(test in Test) <<= (test in Test).dependsOn(customMigrate)
The answer is given in the sbt FAQ section "How can I create a custom run task, in addition to run?". Basically:
lazy val customMigrate = taskKey[Unit]("custom run task")
fullRunTask(customMigrate, Test, "foo.Main", "migrate")
I know that a single test can be ran by running, in sbt,
testOnly *class -- -n Tag
Is there a way of telling sbt/scalatest to run a single test without tags? For example:
testOnly *class -- -X 2
it would mean "run the second test in the class. Whatever it is". We have a bunch of tests and no one bothered to tag them, so is there a way to run a single test without it having a tag?
This is now supported (since ScalaTest 2.1.3) within interactive mode:
testOnly *MySuite -- -z foo
to run only the tests whose name includes the substring "foo".
For exact match rather than substring, use -t instead of -z.
If you run it from the command line, it should be as single argument to sbt:
sbt 'testOnly *MySuite -- -z foo'
I wanted to add a concrete example to accompany the other answers
You need to specify the name of the class that you want to test, so if you have the following project (this is a Play project):
You can test just the Login tests by running the following command from the SBT console:
test:testOnly *LoginServiceSpec
If you are running the command from outside the SBT console, you would do the following:
sbt "test:testOnly *LoginServiceSpec"
I don't see a way to run a single untagged test within a test class but I am providing my workflow since it seems to be useful for anyone who runs into this question.
From within a sbt session:
test:testOnly *YourTestClass
(The asterisk is a wildcard, you could specify the full path com.example.specs.YourTestClass.)
All tests within that test class will be executed. Presumably you're most concerned with failing tests, so correct any failing implementations and then run:
test:testQuick
... which will only execute tests that failed. (Repeating the most recently executed test:testOnly command will be the same as test:testQuick in this case, but if you break up your test methods into appropriate test classes you can use a wildcard to make test:testQuick a more efficient way to re-run failing tests.)
Note that the nomenclature for test in ScalaTest is a test class, not a specific test method, so all untagged methods are executed.
If you have too many test methods in a test class break them up into separate classes or tag them appropriately. (This could be a signal that the class under test is in violation of single responsibility principle and could use a refactoring.)
Just to simplify the example of Tyler.
test:-prefix is not needed.
So according to his example:
In the sbt-console:
testOnly *LoginServiceSpec
And in the terminal:
sbt "testOnly *LoginServiceSpec"
Here's the Scalatest page on using the runner and the extended discussion on the -t and -z options.
This post shows what commands work for a test file that uses FunSpec.
Here's the test file:
package com.github.mrpowers.scalatest.example
import org.scalatest.FunSpec
class CardiBSpec extends FunSpec {
describe("realName") {
it("returns her birth name") {
assert(CardiB.realName() === "Belcalis Almanzar")
}
}
describe("iLike") {
it("works with a single argument") {
assert(CardiB.iLike("dollars") === "I like dollars")
}
it("works with multiple arguments") {
assert(CardiB.iLike("dollars", "diamonds") === "I like dollars, diamonds")
}
it("throws an error if an integer argument is supplied") {
assertThrows[java.lang.IllegalArgumentException]{
CardiB.iLike()
}
}
it("does not compile with integer arguments") {
assertDoesNotCompile("""CardiB.iLike(1, 2, 3)""")
}
}
}
This command runs the four tests in the iLike describe block (from the SBT command line):
testOnly *CardiBSpec -- -z iLike
You can also use quotation marks, so this will also work:
testOnly *CardiBSpec -- -z "iLike"
This will run a single test:
testOnly *CardiBSpec -- -z "works with multiple arguments"
This will run the two tests that start with "works with":
testOnly *CardiBSpec -- -z "works with"
I can't get the -t option to run any tests in the CardiBSpec file. This command doesn't run any tests:
testOnly *CardiBSpec -- -t "works with multiple arguments"
Looks like the -t option works when tests aren't nested in describe blocks. Let's take a look at another test file:
class CalculatorSpec extends FunSpec {
it("adds two numbers") {
assert(Calculator.addNumbers(3, 4) === 7)
}
}
-t can be used to run the single test:
testOnly *CalculatorSpec -- -t "adds two numbers"
-z can also be used to run the single test:
testOnly *CalculatorSpec -- -z "adds two numbers"
See this repo if you'd like to run these examples. You can find more info on running tests here.
The stacktraces are truncated - e.g. they end with [info] ...
Using last or changing traceLevel doesn't help - it simply prints the complete stacktrace of the sbt wrapper.
This is testing with testng (also I believe using scalatest and sl4j)
Using hints found in the documentation here:
(quoted)
You can configure the output shown when running with sbt in four ways: 1) turn off color, 2) show short stack traces, 3) full stack traces, and 4) show durations for everything. To do so you must pass a -o argument to ScalaTest, and after the -o, place any combination of:
D - show durations
S - show short stack traces
F - show full stack traces
W - without color
For example, "-oDF" would show full stack traces and durations (the amount of time spent in each test).
To pass arguments from sbt to ScalaTest you can either add test options globally, like this:
testOptions in Test += Tests.Argument("-oD")
(See the website for the rest of the quote)
You can use the following sbt command to enable full stack traces in tests:
> set testOptions in YourProjectName += Tests.Argument("-oF")
Per Sasha's comment, this can also be done from the command line per test run as shown below.
$ sbt test -- -oF
As an alternative to getting SBT to print the full stack trace, could you put a try-catch block around your test runner? For example, from the REPL:
scala> try { throw new Exception } catch { case e => e }
res1: java.lang.Throwable = java.lang.Exception
scala> res1.printStackTrace
java.lang.Exception
at $line2.$read$$iw$$iw$.liftedTree1$1(<console>:8)
at $line2.$read$$iw$$iw$.<init>(<console>:8)
at $line2.$read$$iw$$iw$.<clinit>(<console>)
...