LiveScript icon indicating copy to clipboard operation
LiveScript copied to clipboard

The tests loop forever if I add a test for the --nodejs flag

Open anko opened this issue 6 years ago • 3 comments

Trying to start on https://github.com/gkz/LiveScript/issues/880#issuecomment-471431184 by adding a failing test like a good developer, but adding this test—

diff --git a/test/cli.ls b/test/cli.ls
index 1013c951..0751e35f 100644
--- a/test/cli.ls
+++ b/test/cli.ls
@@ -94,3 +94,6 @@ command-eq '--no-header -bce "a!"' ['a();']
 
 # json+ast
 command-eq '-aje 1' [ JSON.stringify(LiveScript.ast '1'; null 2) ]
+
+# nodejs
+command-eq '--nodejs -v test/data/data.ls', [process.version]

—makes the tests loop forever:

looping forever terminal output

What's happening?

I tried these things to troubleshoot:

  • Sanity reset: git reset --hard ; npm i ; npm t, then made the same change, but nope, still loops forever.
  • Duplicated the last command-eq line in cli.ls. That works fine, so something about the line I'm adding specifically is making it choke.
  • Changed command.ls to spawnSync the node process instead of spawn. No difference, still loops forever.

Any ideas?


Versions just in case:

$ node -v
v11.11.0
$ lsc -v
LiveScript version 1.6.0
$ git rev-parse HEAD master
bc1c188f01298567bc689c979147829c6ac57213
bc1c188f01298567bc689c979147829c6ac57213

anko avatar Mar 11 '19 15:03 anko

It's not a loop, it's a recursive fork. Using the --nodejs option means that the test process spawns another node process with the same arguments... which means that the child process does what the parent was doing, namely, running all the tests, including the one which caused the fork...

rhendric avatar Mar 11 '19 22:03 rhendric

Oh, I see!

There goes my plan though. :slightly_frowning_face: To make this test work as-is, the forked node process would need to call the provided log and die functions, for commandEq to capture and check. I could do that by piping its stdio through something that calls log/die with converted buffers from its stdin/stdout, but that would destroy performance in non-test use.

I'd be more inclined to refactor test/cli.ls into full end-to-end tests, running a child process lsc for each and checking captured stdio.

anko avatar Mar 12 '19 03:03 anko

It might be better to create a new file in test for end-to-end tests, rather than refactor all of test/cli.ls.

rhendric avatar Mar 12 '19 15:03 rhendric