gkz / LiveScript

LiveScript is a language which compiles to JavaScript. It has a straightforward mapping to JavaScript and allows you to write expressive code devoid of repetitive boilerplate. While LiveScript adds many features to assist in functional style programming, it also has many improvements for object oriented and imperative programming.
http://livescript.net
MIT License
2.31k stars 156 forks source link

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

Open anko opened 5 years ago

anko commented 5 years ago

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:

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
rhendric commented 5 years ago

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...

anko commented 5 years ago

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.

rhendric commented 5 years ago

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