Open AChusuei opened 8 years ago
Sure, we can do that.
My initial thought is to watch the --url option, and default to localhost:3000 if it's not detected. The only only real question is whether we ought to check --url before or after we check if meteor is running. (That sort of depends on whether there's an edge case where we might want to check both. Ping-pong testing? Baselining? It's not completely out of the question.)
https://github.com/awatson1978/starrynight/blob/develop/tool/frameworks/nightwatch.js
There's also the ability to specify an external URL in the script using the .url() method. So it's not unheard of to have a devScript.js and prodScript.js, which works reasonably well for basic load testing. But it would be nice to be able to specify the script URLs on the command line. For that, we would need to look at writing to the globals.js file; which is exactly what it's for.
http://nightwatchjs.org/guide#external-globals
Happy to accept a pull-request on this item.
For the first part, I would say that since the url is specified in the nightwatch.json file anyways, we should look at whatever url is being looked at for the test, and test that with the http request.
For the second one, I'm not sure we should couple the url being tested with the globals.js file.
If I come up with something, I'll let you know.
I often run tests locally using nightwatch on a local meteor instance, but there are times when I would like to run those tests against a different environment, and as such having a local meteor instance started should not be required. Is it possible to remove the code that requires meteor to be running?
Or is meteor absolutely required to be running for some reason, if we are conducted tests on a different environment?