Discuss: add the python project attribute to git extras repository about git-extras HOT 6 CLOSED

Emm.., I think is useless to add the package manager for git extras repo cause the installation is a problem or just waste the time and the information about the test in the readme should be moved to a new file in the test directory, it is special for the dev who want to create some testcases.

from git-extras.

If we use Python, in my opinion Poetry is a very useful tool to make managing things easier. I didn't mention it before because not everyone uses the tool. If you would like to add it, you certainly have my vote!

I'm not convinced that we need testpath. If we need to mock a command, I think we should do it ourselves. But I'm not the one writing the majority of tests.

I agree with your points that instructions for setting up Python for testing should not be included in the main README.md.

from git-extras.

Emm.., I think is useless to add the package manager for git extras repo cause the installation is a problem or just waste the time and the information about the test in the readme should be moved to a new file in the test directory, it is special for the dev who want to create some testcases.

Agree with that.

If you would like to add it, you certainly have my vote!

Vote +1 for this too.

from git-extras.

Thanks guys and I will try to restruct the test env for git extras later.

I'm not convinced that we need testpath.

Because of the definition of the git-browse that it will lead the user to a website which display current repository. Normally, the xdg-open can help us to do like that, but the xdg-open is not the part of our functions, we just use it in a special environment, here is linux or unix. I call the part like xdg-open as external API and the external API should be mocked when do unit tests. So I think we should has a mock library to help us. Mocking system commands is a great way to detach the external API for git-browse unit test.

from git-extras.

@vanpipy I don't disagree that we need a way to mock commands, and I did mention:

If we need to mock a command, I think we should do it ourselves.

The simple thing we can do is add a directory, tests/bin to the PATH only when testing, which contains the mocked commands. I think this approach is more clear and approachable for someone not familiar with the codebase; it's an approach that isn't uncommon and is not coupled to a particular library.

from git-extras.

The simple thing we can do is add a directory, tests/bin to the PATH only when testing, which contains the mocked commands. I think this approach is more clear and approachable for someone not familiar with the codebase; it's an approach that isn't uncommon and is not coupled to a particular library.

I got your idea and it is my fault about the mock commands. Let me take some explains.

• what is the mock commands called and how to be used?
  • It is a temp file or process or only a function.
  • It can be detected used or not.
  • One mocked command works in the python environment.

Once we create the mocking directory and then a python wrapper is needed. It means we need to maintain one more python library. So could the tests/bin satisfy the requirements above easily? It depends cause I review the implement of the testpath did lots of thing I cannot understand for now.

I agree and will to do the tests/bin, but I do not know how many time used. This is why I want to use testpath.

One more, all things we talked about did not affect the git extras itself. Could i misunderstand a particular library?

from git-extras.