I'm using behave with Appium in a PyCharm debugger to debug an app. I am calling behave from Python using this code:
rc = run_behave(config=myconfig, runner_class=MyBehaveRunner)
How can I intercept the debugger's [STOP] button/signal and call context.driver.quit() on the driver so that the Appium server terminates the current session id instead of eventually timing out? context.driver (for calling context.driver.quit() ) only seems to be accessible within a behave step, so I don't know how to set up a signal handler to do this.
Related
I try to build a little REST service with Julia and Genie library. The last command is up(8888).
When I start this from Julia REPL all is ok.
When I start it from command line like >julia myrestapi.jl the program starts and stops immediately, i.e. up() doesn't go into an infinite loop.
What can I do to keep the server running?
When the Genie server is initiated in asynchronous mode, it runs off the main Task, and allows script processing to continue. If the script ends, the whole process and its spawned Tasks are stopped. This behavior is not good for a running web-service. To keep this from happening, two suggestions are:
Don't run the server off the main Task, by running synchronously. In code:
Genie.config.run_as_server = true
...
Genie.Server.up()
Make sure the main process does not end until the server Task ends. In code:
Base.JLOptions().isinteractive == 0 && wait()
The isinteractive condition, runs the wait() only when it is running as a script, as the usual desire when a REPL is present in interactive session, is to issue more commands, and the REPL keeps the server Task running in the background.
I have a Windows 10 LTSB 2016 machine set up in kiosk mode to run a single application. I followed the Powershell instructions at https://learn.microsoft.com/en-us/windows/configuration/kiosk-shelllauncher#configure-a-custom-shell-using-powershell to build the install script, it works well. In that script, I can set the behavior of the shell if the application crashes. I can restart the application, restart the PC, or shut down the PC.
In general, this is all good, but occasionally someone does something like edit a file that causes the application to instantly crash on starting. Because I have the script set to restart the application, this causes the shell to get stuck in a loop where the application is rapidly crashing and restarting. This fills my logs and is generally a poor UX for the end user.
I'd like to condition the behavior so the application only attempts to restart a limited number of times, then shuts down (or some other behavior). Is there any way to achieve this? Can the custom shell access a counter, or accept a return statement from the application (e.g. to differentiate between an intended application shutdown/restart vs an application crash)?
When running my automation tests I need to run code in my browser before angular is initialised.
I have tried the mockModules approach:
function setupBrowser(){
console.log(`Setting up browser`);
}
browser.addMockModule('someRandomStringNotAModuleName', setupBrowser );
browser.get('myAppUrl');
but I never see the setting up browser message in the browser console. I imagine that this is because I am not trying to mock an angular module, I am just trying to execute code before my app boots.
Is there an alternate way of doing this?
I need to run this code after I have navigated to my angular app but before angular boots because I am listening for start and stop messages from my app. I have a function that waits for stop messages. If there has been no start message it returns immediately.
If I can't run code before angular boots I can't be sure that I have captured all start messages correctly.
Thanks
Your automation tests will not start unless it encounters the onPrepare segment in your configuration file. If you want any code to execute before your browser starts executing your tests, onPrepare is the place to put it.
If you want to execute something before the browser even starts, you will have to add a script that executes the functionality you require and add it to the package.json "script" to execute before your protractor conf.js executes.
I have a script invoked from rc.local which start up a java process. When all X related things have finished, this java process starts a C++ process which call gtk_init. this call gives following error:
(gstinterface:2828): Gtk-WARNING **: cannot open display:
If I run first script manually from a terminal, all works fine. What could be the reason?
The error message is telling you the reason: it cannot open a display connection.
Usually that happens because there is no DISPLAY variable exposed in the environment; you will have to export that.
Be warned that using rc.local to launch a GUI application is a very bad idea. If you need to launch the application alongside X11 you should use the X11 session scripts, or modify the script you use to launch X11.
I've setup a Eclipse kepler (v4.3.2) with Chromium JavaScript Remote Debugger to be able to remote debug a node.js process (Connect to V8Debugger).
Then I have started protractor with
node --debug-brk protractor.js conf.js
Where protractor.js is the shellscript file inside the bin folder of the node_module protractor directory missing the first line which starts node.
So node is then startet in debug mode listening on port 5858 for debugger connection.
Inside eclipse I have configured a Standalone V8 VM Debugger Configuration for connecting on local port 5858.
After connecting to the node.js server it hits the first breakpoint inside the protractor.js file.
But when resuming/continue execution it repeats "debugger listening on port 5858" inside the console and do not continue with testing.
Can someone tell me what's the problem with this?
Regards,
Sebastian
Ok here is the answer:
How to debug Node.JS child forked process?
In Short: It is a bug in node.js v0.10 where it is impossible to debug child processes.
But it is still possible to debug the childprocess also:
And as a amendment here is my solution:
Change the code inside launcher.js to fork the childprocess with --debug-brk also! And give it a unique port as explained in the posted link above.
Then you need to set a breakpoint (or put debugger; inside the code) before the childFork.process.send('run',...) function to stop the code from sending the message to the forked process.
This is needed because you have stopped the childprocess from running by setting --debug-brk. So connect to the second process and hit continue. You will see that the childprocess (runFromLauncher) will wait until message 'run' is received. and so switch back to the first debugger, hit run and let it send the message to the childprocess.
You will see, if you set a breakpoint inside the process.on.message(...) function in runFromLauncher.js, you can step through the code again.