test: remove TODO comment

[Trott]

Implement task from TODO comment.

[Trott]

ref: #264

[brendanashworth]

Is there a way to test both, that way we don't introduce randomness into tests?

[Trott]

I don't like the random either but decided that I should stick to the TODO recommendation at least as a first pass.

I thought about running each test twice, once with -r and once with --require, but that misses the edge case of using both.

I think the best thing to do might be to put these tests back they way they were (using -r always) and just add two more tests: One that uses --require and one that uses both.

[Trott]

I think the best thing to do might be to put these tests back they way they were (using -r always) and just add two more tests: One that uses --require and one that uses both.

Would that work for you, @brendanashworth?

[brendanashworth]

IMO I don't think we should bulk it up to three tests if we can keep it in one - they don't really test very different functionality.

Sorry, what do you mean "edge case of using both"?

[dcousens]

Wrap the preloads.forEach in

['-r','--require','-r --require'].forEach(function(optionString){// preloads.forEach ... etc})

and call it a day?

The test itself should be fast, so I don't see why this isn't worth doing?

[Trott]

@brendanashworth The edge case I was thinking of is node -r module1 --require module2. Thinking about it now, that can probably just be dropped. We don't test combinations of other command line flags--they just get tested individually.

So maybe just go with a simplified version of @dcousens's suggestion and wrap it in [-r', '--require'].forEach()`?

[Trott]

I pushed a new commit that runs each test twice, once with each flag. No randomness. No mixed use of both flags at the same time, but that's not in the existing tests either, so this is still an improvement. And probably no need to go down the slippery slope of flag combinations (not to mention ordering) unless/until an actual bug is discovered.

[jbergstroem]

I agree that this [edit: as suggested in todo] kind of randomness doesn't belong in tests but if we really want to start testing option parsing I think that should be done somewhere else (keen on growing cctests for instance).

[brendanashworth]

minute-style: no space in function (flag), so function(flag)

[brendanashworth]

Besides the style nitpick this LGTM. Thanks!

[brendanashworth]

@jbergstroem perhaps that could be added as part of #1804?

[jbergstroem]

@brendanashworth yeah. I don't see why we should waste time testing the same thing twice in here, is all.

[brendanashworth]

@jbergstroem from what I can see, it does increase the test run time by ~2 seconds, so your concerns are well placed. Do we know what is done for other things like this?

[jbergstroem]

@brendanashworth What do you mean by 'like'? In this case, my opinion is that we shouldn't test the same thing twice. If we want to make sure that the flags does the same thing, I suggested it be added to #1804 (just as you said :).

[brendanashworth]

@Trott do you object to closing this for now with the goal of later testing it in the C++ tests?

[Trott]

How about I remove the loop and basically leave the tests as they were before (so we're not testing the same things with -r and --require twice), but remove the TODO comment about randomizing the flag? So the pull request will just remove a comment that is suggesting introducing randomness into the test.

[jbergstroem]

@Trott SGTM :)

[Trott]

OK, updated the commit so it's just removing the comment. Also updated the name of the pull request to better reflect what is now happening.

[brendanashworth]

r=@jbergstroem

[jbergstroem]

LGTM

[brendanashworth]

Thanks, landed in d9ddd7d.