-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test to invoke onigumo from CLI #159
Conversation
There are two options, not mutually exclusive:
I think both are good to have. For the latter, we’d need to specify a Behaviour. That is not only a good learning opportunity but a correct thing to do too. The Downloader is a module with a public interface: the main function. |
Now I see, however, that Behaviours are deprecated. I need to explore that more.
It’s probably just a syntactic change in how Behaviours are defined, not a deprecation of the idea itself. More reading here: https://hexdocs.pm/elixir/typespecs.html#behaviours |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The integration test will be almost identical to the existing “main” function test:
- Prepare a list of URLs to download.
- Invoke the Downloader.
- Check the downloaded files.
A technical note: keep only the integration tests in this PR. For the future unit test, extract the behaviour introduction and the actual test into separate PRs.
@nappex, is everything clear? Do you have all the information you need to complete this pull request? Can I provide any help? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I recall correctly, you addressed this during our last meeting and had written an integration test for it, right? If that's the case, let's make sure to finalize it. We need that test in place. Let me know if you need any help or if there's anything I can do to assist you.
- These functions was moved because we need them in more tests then just one
- when we move the file to folder support util in name is extra. The mean of util is include in folder name support
It is ready to review and merge. There are two not ideal approaches:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💥
mix.exs
Outdated
@@ -8,7 +8,8 @@ defmodule Onigumo.MixProject do | |||
elixir: "~> 1.10", | |||
start_permanent: Mix.env() == :prod, | |||
deps: deps(), | |||
escript: escript() | |||
escript: escript(), | |||
elixirc_paths: elixirc_paths(Mix.env()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking about extracting Mix.env()
to a variable to save two identical calls.
mix.exs
Outdated
@@ -8,7 +8,8 @@ defmodule Onigumo.MixProject do | |||
elixir: "~> 1.10", | |||
start_permanent: Mix.env() == :prod, | |||
deps: deps(), | |||
escript: escript() | |||
escript: escript(), | |||
elixirc_paths: elixirc_paths(Mix.env()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a nice rabbit hole to find out where elixir_rcpaths is defined. Noting it here for future generations:
mix test
, as its first step, starts the application. That is, it runsmix run
. (reference)
This task starts the current application, […]
mix run
compiles the current application before starting it. That is, it runsmix compile
. (reference)
Before doing anything, Mix will compile the current application […].
mix compile
runs all compilers. Among them,mix compile.elixir
. (reference)
It simply runs the compilers registered in your project […].
[…]
:compilers
- compilers to run, defaults to Mix.compilers/0, which are[:yecc, :leex, :erlang, :elixir, :app]
.
mix compile.elixir
uses theelixirc_paths
to find source files. (reference)
:elixirc_paths
- directories to find source files. Defaults to["lib"]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point we should look at closer!
mix.exs
Outdated
defp elixirc_paths(:test), do: ["lib", "test/support"] | ||
defp elixirc_paths(_), do: ["lib"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we define a common elixirc_path
function that would return the default list of ["lib"]
and only add test/support
to that in case of :test
? By explicitly mentioning "lib"
here, we duplicate what’s already defined in Mix instead of adding to that.
mix.exs
Outdated
@@ -8,7 +8,8 @@ defmodule Onigumo.MixProject do | |||
elixir: "~> 1.10", | |||
start_permanent: Mix.env() == :prod, | |||
deps: deps(), | |||
escript: escript() | |||
escript: escript(), | |||
elixirc_paths: elixirc_paths(Mix.env()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mix.env()
is called twice. We can save the repeated call by storing the returned value to a variable.
fix #158
We dont test invocation Onigumo from CLI at this moment.
We should add some basic test to test that commands
$ ./onigumo
or$ ./onigumo Downloader
in terminal are running without an error.Unfortunately I have no idea how should be tested... So the PR is just draft to discuss..