search

randycoulman / mix_test_interactive

Interactive watch mode for Elixir's mix test. https://hexdocs.pm/mix_test_interactive/
MIT License
85 stars 12 forks source link

How to work with --name and --sname #59

Closed humpangle closed 1 month ago

humpangle commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

jfpedroza commented 1 year ago

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 commented 1 year ago

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

jfpedroza commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

jfpedroza commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

Alright. No pressure.

randycoulman commented 1 month ago

@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!