With the junit-interface runner, there was this handy option:
-q Suppress stdout for successful tests. Stderr is printed to the
console
normally. Stdout is written to a buffer and discarded when a test
succeeds. If it fails, the buffer is dumped to the console. Since stdio
redirection in Java is a bad kludge (System.setOut() changes the static
final field System.out through native code) this may not work for all
scenarios. Scala has its own console with a sane redirection feature. If
Scala is detected on the class path, junit-interface tries to reroute
scala.Console's stdout, too.
I was wondering whether there was an easy way to make scalatest do the same thing. I can try to redirect the output myself but would prefer to use something standard if possible.
According to this info on the ScalaTest website, you can set some flags to suppress some messages:
If you add a line like this in your build.sbt, your logger will not show successful tests in the stdout:
testOptions in Test += Tests.Argument(TestFrameworks.ScalaTest, "-oN")
Actually that is a question that was asked on github, at the scalatest repository. You can find it here.
As suggeted there, you can add -oNCXEHLOPQRM to the running options. It means that in your sbt you need to add:
testOptions in Test += Tests.Argument("-oNCXEHLOPQRM")
That alone will might be sufficient, as sbt itself logs its own startup, and that all tests passed. If you want to get ONLY the failed tests, you can add the -error flag to the sbt command, and then it will skip the info log level.
In such case, when all tests passes the output will be completely empty.
An example to such a command will be:
sbt test -error
If you want to further read about the scala test configuration report, you can do it here. They have plenty of options.
Related
Every time I use sbt the first thing I do is set the log level to Error:
$ sbt
// ... sbt loads
[my_project] $ error
[my_project] $
Several places on SO and elsewhere recommend adding this to either your build.sbt or your sbt.boot.properties:
set logLevel in run := Level.Error
But I'm working in a shared project with many developers and I don't want to change the log level for everyone, just me! I do currently use SBT_OPTS to tailor sbt's memory usage on my machine, and this may potentially be an option but I can't find any guidance on what format to pass options via SBT_OPTS except for Java things like pass -Dkey=val directly to the java runtime and memory parameters like -Xmx8G.
sbt --help indicates that .sbtopts may also be a potential option:
.sbtopts if this file exists in the current directory, its contents
are prepended to the runner args
But as far as I can tell there are no method to specify command-line "runner args" that set the log level to Error, only for setting the log level to debug via --debug.
I'm a little stumped, I've identified at least two potential avenues (SBT_OPTS and .sbtopts) for passing machine-specific customization to sbt, but do either of these support setting the log level to Error? Or is there a third avenue I'm missing, maybe some elusive ~/.sbt, that I could use to set my machine's sbt log level to Error?
Put the following in $HOME/.sbt/1.0/global.sbt
logLevel := Level.Error
All available log level options are:
Error
Warn
Info
Debug
Thanks #maxkar for leading me to this solution
I would like to use a scala REPL console for Gatling to debug some code and evaluate it.
Is there any easy way to do that? Is there a fast way to do a syntax check on Gatling scripts?
If you're using SBT, you can always take advantage of SBT's console task to get Gatling in your classpath and and experiment with its APIs, but you won't be able to execute requests, etc... from the REPL.
The next best solution is to use Gatling's SBT plugin (https://github.com/gatling/gatling-sbt) : using it, you can quickly compile and run your simulations, even launch them on every successful compilation until the result suits you.
I am new to Scala and to using emacs + ensime + sbt setup for my Scala development.
This setup is quite nice and light, but there is one thing which drives me nuts - inability to auto-compile / reload changes into Scala console started from sbt.
I use REPL a lot and would like to be able to start REPL from sbt with console command and test my changes to scala classes from REPL without having to close it and reload every time I make a change.
I come from Erlang environment and this way of development is easy with Erlang but seems to be difficult with SBT. I have the JRebel plug-in installed but it doesn't seem to be working for the situation I described.
Has anybody been able to make something similar work and would be willing to share the configuration steps?
Much appreciated in advance.
There are two things possible in sbt:
Causing automatic recompilation of the project sources triggered by a file change by prefixing a command with ~ (tilde). The console, or console-quick, or console-project commands can be prefixed, too, but you have to exit REPL to make the recompilation happen (just hit Ctrl+D and wait.)
Causing automatic execution of REPL commands just after firing the console. They can be defined as properties (e.g. in build.sbt):
initialCommands in console := """
import some.library._
def someFun = println("Hello")
"""
It's not necessary to define the property separately in consoleQuick because it defaults to the one defined in console, but if you would like to use the console-project command you have to define it separately.
On a final note: remember to leave empty line between every property in an *.sbt file. They're necessary to parse the properties correctly. In the example above there are no blank lines in between so it means that everything goes into the initialCommands property (and that's what we want.)
When running SBT test from the terminal, after a while tests hang without throwing an error.
How do you allocate more memory to the test runner?(if needed)
Is there a log file anywhere? Can't find anything in the docs.
The Eclipse integration of ScalaTest is rubish, are there better alternatives?
last:test is useless since no error is actually thrown.
If your test is hanging up, then my first suspicion is that you may have an infinite tail recursion somewhere. I doubt that (1) will help you since typically you will get an OutOfMemoryError or some other error if you don't have enough. (2) The only logging I'm aware of is printed to the console. (3) You're already doing the right thing by using the console.
Disable parallel execution of your tests to allow you to determine which test is getting stuck and if it is consistently the same test, then go from there. Add this to your build.sbt:
parallelExecution in Test := false
I've been looking in to using Py.Test to automate unit testing in some code I've been working on. I've discovered the following behavior: when a test that I've built has an error (that would otherwise cause the interpreter to barf), the testing framework seems to silently ignore the test altogether.
I'm worried that, as I implement more tests, I'll mistake "this test had an error and didn't run" for "this test passed". Ideally, I'd like to hit a button in Eclipse and have a unit test fail if it has a syntax error in it. Other than "Why don't you write code without syntax errors in it?", is there another solution I'm missing?
Alternatively, is there a way to make Py.Test tell you what test files were found, and which ones were run?
Setup is PyDev 2.7.1 and Eclipse 4.2, with Python 2.7.3 and PyTest 2.3.4.
I think the issue has to do with one of the command line options I set in Preferenced -> PyDev -> PyUnit. I had been running with -n 4, which splits the tests up over processors. This seems to have suppressed the syntax errors. The same option also made debugging not work (i.e., breakpoints were skipped) which seems pretty obvious in hindsight.