Skip to content
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

Merged
merged 12 commits into from
Oct 1, 2023
Merged

Add test to invoke onigumo from CLI #159

merged 12 commits into from
Oct 1, 2023

Conversation

nappex
Copy link
Collaborator

@nappex nappex commented Jan 15, 2023

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..

@Glutexo Glutexo self-requested a review January 16, 2023 10:48
@Glutexo
Copy link
Owner

Glutexo commented Jan 16, 2023

There are two options, not mutually exclusive:

  • An integration test that would run the actual Downloader, only with HTTPoison mocked.
  • A unit test that would test the CLI module but wouldn’t use the actual Downloader.

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.

@Glutexo
Copy link
Owner

Glutexo commented Jan 16, 2023

Now I see, however, that Behaviours are deprecated. I need to explore that more.

This module is deprecated. Use @callback and @macrocallback attributes instead.

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

Copy link
Owner

@Glutexo Glutexo left a 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:

  1. Prepare a list of URLs to download.
  2. Invoke the Downloader.
  3. 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.

test/onigumo_cli_test.exs Outdated Show resolved Hide resolved
@Glutexo
Copy link
Owner

Glutexo commented Feb 6, 2023

@nappex, is everything clear? Do you have all the information you need to complete this pull request? Can I provide any help?

Copy link
Owner

@Glutexo Glutexo left a 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.

test/onigumo_cli_test.exs Outdated Show resolved Hide resolved
nappex added 3 commits May 20, 2023 17:46
   - 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
mix.exs Outdated Show resolved Hide resolved
@nappex nappex marked this pull request as ready for review May 23, 2023 09:54
@nappex
Copy link
Collaborator Author

nappex commented May 23, 2023

It is ready to review and merge.

There are two not ideal approaches:

  1. we change cwd, because the root_path is set as constant and code does not see created files needed to further processes. For this case was issue created Fix tests with root_path #184 so it should be fix by another PR.
  2. This PR does not test invalid inputs to CLI. There is an issue for that case Test CLI for invalid input #183

@nappex nappex mentioned this pull request Jul 29, 2023
Glutexo
Glutexo previously approved these changes Jul 29, 2023
Copy link
Owner

@Glutexo Glutexo left a 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()),
Copy link
Owner

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())
Copy link
Owner

@Glutexo Glutexo Jul 29, 2023

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 runs mix run. (reference)

This task starts the current application, […]

  • mix run compiles the current application before starting it. That is, it runs mix 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 the elixirc_paths to find source files. (reference)

:elixirc_paths - directories to find source files. Defaults to ["lib"].

Copy link
Collaborator Author

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
Comment on lines 42 to 43
defp elixirc_paths(:test), do: ["lib", "test/support"]
defp elixirc_paths(_), do: ["lib"]
Copy link
Owner

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.

test/onigumo_cli_test.exs Show resolved Hide resolved
test/support/input.ex Outdated Show resolved Hide resolved
test/support/http.ex Outdated Show resolved Hide resolved
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())
Copy link
Owner

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.

@Glutexo Glutexo merged commit a8425aa into Glutexo:master Oct 1, 2023
@Glutexo Glutexo deleted the cli branch October 1, 2023 18:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Test Onigumo CLI
2 participants