Suggestions

[christian-bromann]

First of all great work on this 👏

I am wondering if we can somehow integrate this better into WebdriverIO with a service. Your repl is only working for Atom right now. Do you think we can build it as a service where user can stop the testrunner process and use the repl from command line? It would be awesome if we could return even results from multiple browser running concurrently. What do you think?

[kurtharriger]

I did initially start with the idea of a wdio-repl service that would start a repl in the background at the before hook. This worked okay, you could access the browser and send commands when any test was paused at a debug statement.

My very first proof of concept was spawning a node repl on a tcp socket https://nodejs.org/api/repl.html from the before hook in wdio.conf and using readline with telnet as the client which is pretty close to what your looking for as a simple terminal client.

But in my search for a way to integrate this into atom I found ijavascript and hydrogen. The repl actually supports the jupyter messaging protocol via a hacked up version of ijavascript. Jupyter is often used for data analytics projects where people want a repl like environment but with support for charts and graphs which aren't supported in a terminal. hydrogen is an atom plugin that knows how to speak jmp, but there are plugins for other editors or one can use the standard jupyter web client.

The problem I ran into starting the repl in a before hook was I didn't have access to any variables in my test and since we often generate new data with often random ids it wasn't as useful as I had hoped for so I decided use a repl command with a callback to eval the code (This allows read/write access to local variables, but it doesn't work so well for running code that creates a new variable but global works).

The repl is still appealing in some ways, I like being able to effectively run the code as I write it in the editor, but I think perhaps it might be better to go lower level and use the node debug protocol, which made me ask again why I wanted a repl and don't I just use node-inspector. Some of the reasons where node-inspector doesn't work:

• It's slow to start felt more disjointed from the development experience. (another co-worker pointed out ironnode as an alternative debugger that's supposedly faster and more extensible than node-inspector).
• The console works well for sync code (fibers actually works in node inspector), but not so well for async code and promises.
• requires sourcemaps
• I also wanted to be able to copy and paste bits of es6 code including await statements which I couldn't do in node-inspector.
• I wanted to take the code I'd written and paste it back into my test but if I have to write it differently in the console due to promises and such I couldn't do that either.