SBT to run Play app exits immediately when started using scala.sys.process.run? - scala

I am writing an integration test that needs to start up several applications. One of these applications is a Play one as a SBT project called appA.
I am able to start the app on the right port using scala.sys.process as follows:
import scala.sys.process._
import org.scalatest._
class Main extends FeatureSpec with Matchers{
val app = Seq("sbt", "project appA", "run 7777").run
println(app.exitValue)
}
The spawned application however exits immediately with return value 0. No errors are displayed to the console. I just see:
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:3000
(Server started, use Ctrl+D to stop and go back to the console...)
[success] Total time: 1 s, completed Feb 27, 2014 10:26:56 PM
0
The 0 at the end of the output is from calling exitValue on the created process. exitValue blocks until the spawned process exits.
How can I run the Play application without it exiting immediately? Is there a better way to start the application?

SBT has 2 run modes - interactive and batch. If you run without any args it goes to interactive mode and does not exit. When you run it by passing commands it runs in a batch mode and exits when the last command is complete. It does not matter if your application inside SBT runs in a forked JVM or not.
Thus to "fix" it you can apply this hack: add ~ command to the end of the list of sbt commands/args:
val app = Seq("sbt", "project appA", "run 7777", "~").run
~ is used to watch source code for changes and recompile when it happens. Thus SBT will never exit unless stopped by a user or killed.
A cleaner way would be to run Play application in a Jetty container (assuming you have WAR to run) or such by calling a main class that starts up Jetty with a command like java com.example.MyMain but that requires additional setup.

Related

How to keep Scala Process Alive?

I type "sbt run", and compilation is ok, the server binds to the port, and then the process quietly terminates. How can I keep the process alive though? (I'm running an akka tcp server pulled straight from the akka docs -- should remain alive.)
Pseudocode:
object Main extends App {
val ac = ActorSystem();
val s = ac.actorOf(WebSocketManager.props());
}
Edit: The process stays alive after adding into build.sbt:
Compile / run / fork := true
Not sure what this does or if correct, but it works.

Any idea why flaky plugin is not triggered on failed tests decorated with #pytest.mark.flaky(max_runs=...)

I have a pytest suite running in this env:
Test session starts (platform: linux, Python 3.6.1, pytest 3.3.1, pytest-sugar 0.9.1)
plugins: flaky-3.5.3, dependency-0.3.2, forked-0.2, logger-0.4.0, sugar-0.9.1, xdist-1.24.1
I have a parametrized test, decorated with flaky, and it is supposed to be re-run max three times if it fails.
#pytest.mark.flaky(max_runs=3) # re-run this test in case it fails
def test_cucubau(getBauBau_fixture):
assert cucubau(getBauBau_fixture) == True
However, it fails only once, it is not re-run, and my flaky test report is empty.
===Flaky Test Report===
===End Flaky Test Report===
Based on what I read about flaky plugin, the usage should be trivial.. but I'm not able to see what is wrong with my code.
any idea?
I believe you need the pytest-rerunfailures plugin for that to work. Then you should be able to annotate your test with #pytest.mark.flaky(reruns=3).

How to debug JavaScript tests in JHipster applications using Karma?

I have a simple monolithic application generated using JHipster v4.10.1 with front-end using Angular 4.x. To run JavaScript unit tests, as suggested in the documentation I ran
./node_modules/karma/bin/karma start src/test/javascript/karma.conf.js --debug
The command runs the tests, reports coverage summary and exits, whether tests all pass or some test fail does not matter. Test run output does show at one point that the debug server is loaded:
21 11 2017 13:41:20.616:INFO [karma]: Karma v1.7.1 server started at http://0.0.0.0:9876/
But because the command exits, the Karma debug server can not be accessed. How to run tests so that Karma console can be used in browser to debug?
Figured out that the magic flag is actually single-run which seems to be true by default. So the main command to run for JS debug is:
yarn test --single-run=false
which in turn runs
$ karma start src/test/javascript/karma.conf.js --single-run=false
With this the command will only exit with explicit kill e.g. with Ctrl+C or Z. Karma debug console can then be accessed on http://localhost:9876/debug.html (assuming default port is not already busy. If it is, test output should tell you which port was chosen).
Additionally you need to disable minimization (and also istanbul config - not sure why) so that you can breakpoint and step through the .ts code in debugger easily. I figured this is done by making following changes in webpack/webpack.test.js file:
Remove following istanbul config from module.rules array:
{
test: /src[/|\\]main[/|\\]webapp[/|\\].+\.ts$/,
enforce: 'post',
exclude: /(test|node_modules)/,
loader: 'sourcemap-istanbul-instrumenter-loader?force-sourcemap=true'
}
Add minimize: false to the LoaderOptionsPlugin under plugins array:
new LoaderOptionsPlugin({
minimize: false,
options: {
tslint: {
emitErrors: !WATCH,
failOnHint: false
}
}
})

How to kill a JUnit test run in Eclipse that has entered an infinte loop

I have some Java code that I am unit testing using JUnit, running inside Eclipse (Neon). It so happens that some code under test has a bug in it, causing it to enter an infinite loop. The JUnit run then, of course, does not finish. How do I kill the test run?
The button for stopping the test run ("Stop JUnit Test Run") does not work well: the GUI seems to think that it has stopped the test run, but a look at the CPU activity (using top, for example), shows that a Java thread is still running. I can kill the thread myself by sending it a kill signal. But that seems a kludge and is inconvenient. Is there a better way, available within Eclipse itself?
Kill it from the console view, using the red button. This stops the process.
Stopping it from the junit view only asks it to stop.
You can handle such things with JUnit by specifying a time-out within
the #Test annotation. For example:
// Simple test-case which will always fail with time-out
#Test(timeout = 1000 * 60) throws Exception // 60 seconds
public void testSomething() {
for (int i = 0; i < 100; i++) { // 100 seconds
Thread.sleep(1000);
}
}
If your test method doesn't finish on time,
then JUnit will interrupt it and report a test failure.
For the example above it will be:
java.lang.Exception: test timed out after 60000 milliseconds
at java.lang.Thread.sleep(Native Method)
at my.package.Test1.testSomething(Test1.java:12)
First, try Matthew Farwell's answer. If that doesn't work then you have to go to your processes running (ctrl+shift+esc on windows, then processes tab) and select the java.exe task, then end process. In the event you ever need to kill eclipse, it's javaw.exe

How do I turn off the Scala Fast Compilation server's (FSC) timeout?

I am using a Scala compilation server. This is probably not related to my IDE IntelliJ IDEA, but I will just inform you that I start the Scala compilation server through a special run configuration in that IDE.
After some time that goes by without compiling anything, the compilation server terminates, without any message. Usually, I only notice this when I try to compile something and compilation fails. Then, I need to start the compilation server again, and of course the next compilation takes a long time, because it's once more the first compilation since starting the compilation server.
How do I turn off that timeout? I looked at the manpage for scalac, and there seems to be no option for it. I can add VM options for that run configuration.
Pass -max-idle 0 as parameter. It will work on a very (very!) recent nightly, and it should be available on Scala 2.9.0 when it comes out. However, there's no guarantee the name won't change until then.
I don't think you can. Here is a code snippet from the compilation server:
object SocketServer
{
// After 30 idle minutes, politely exit.
// Should the port file disappear, and the clients
// therefore unable to contact this server instance,
// the process will just eventually terminate by itself.
val IdleTimeout = 1800000
val BufferSize = 10240
def bufferedReader(s: Socket) = new BufferedReader(new InputStreamReader(s.getInputStream()))
def bufferedOutput(s: Socket) = new BufferedOutputStream(s.getOutputStream, BufferSize)
}
I think you should open a feature request in scala-lang.org