How to work with --name and --sname

[humpangle]

Thanks for the project.

If I start my test with:

elixir --sname foo -S mix test.interactive

And I inspect node() from the test, I get :nonode@nohost.

On the other hand, when I launch the test like so:

elixir --sname foo -S mix test

I get :foo@my_host

Is there an option to make mix test.interactive work with --sname and --name?

[randycoulman]

@humpangle I have never tried using --sname for running my tests, so I'm not sure what it would take to make that work. Under the hood, mix test.interactive spawns new mix test invocations for every test run, so we'd likely have to find a way to pass the initial elixir arguments to those spawned invocations.

I'm not likely to have time to investigate this in the near future, but I'd be open to a pull request that solves the problem for you.

[humpangle]

Thanks - I understand. I will see if I can make a PR.

[jfpedroza]

You would probably need to support a --sname option in mix test.interactive and run like mix test.interactive --sname because if you do elixir --sname foo -S mix test.interactive, that name will already be taken by the interactive VM and elixir --sname foo -S mix test will fail.

[humpangle]

Thanks @jfpedroza for the suggestion. I'll take it into consideration.

[jfpedroza]

Another option is not to run a shell command and run the task directly with Mix.Task.run. But I don't know if there is a reason for why that wasn't done like that in the first place.

[randycoulman]

@jfpedroza I just realized that I never responded to your comment about why this library doesn't use Mix.Task.run. The main reason is that mix test does a bunch of other work before running the tests, like re-reading any changed config files and recompiling changed files. We'd have to reimplement all of that behavior here and then make sure to keep it up to date whenever mix test changes.

[randycoulman]

@humpangle Would #63 be an adequate solution to the issue you're raising here?

[jfpedroza]

@jfpedroza I just realized that I never responded to your comment about why this library doesn't use Mix.Task.run. The main reason is that mix test does a bunch of other work before running the tests, like re-reading any changed config files and recompiling changed files. We'd have to reimplement all of that behavior here and then make sure to keep it up to date whenever mix test changes.

Yeah, I tried it. It didn't like that the test modules were already required the second time.

[humpangle]

@humpangle Would #63 be an adequate solution to the issue you're raising here?

I will check out and revert back to you. Thanks.

[humpangle]

@randycoulman #63 does work for me. I just checked by editing my deps/mix_test_interactive/lib/mix_test_interactive/port_runner.ex line 44 directly and substituting with a shell script.

[randycoulman]

@humpangle Thanks for letting me know. I'm not sure how soon I'll have time to implement that solution, but it looks like the right way to go at least.

[humpangle]

Alright. No pressure.

[randycoulman]

@humpangle At long last, I've implemented the command configuration option and released it as v3.1.0. Please try it out and let me know if it works for you (if you're still interested).

I'm going to close this issue in the mean time. Feel free to re-open if the new option doesn't meet your needs. Thanks!