Testing is unable to find test.py about sh

[ecederstrand]

Running tests using tox is supported, but only within the Docker container provided in tests/Dockerfile. I agree it's a bit misleading to provide a top-level tox.ini that's not intended to be run directly from the current system. I think we should just move our tox.ini to tests/tox.ini. Would that help your automated packaging script?

[ecederstrand]

It would be helpful if you provide some more information. Where did you find the advice to run tests this way? How did you set up your test environment?

In general, there are two ways to run tests - Using Docker as described in the README, or using poetry as documented in https://github.com/amoffat/sh/blob/1c0dc81fb7fb7fd1d23d80082498ad3059154e79/.github/workflows/main.yml

[mtelka]

I'm packaging sh for OpenIndiana (together with hundreds other Python projects) and during the package build the build framework runs tests. When a project supports tox (i.e. tox.ini file is present) then the default and so far almost always[1] working way to run tests is just to invoke something similar to tox -e py39[2].

Since I package sh for an operating system where the package will be run in real and current environment (not in a virtual one) then there is little sense to test sh using docker for my use case.

If I parsed the main.yaml file properly then the actual command to run tests should be this:

SH_TESTS_RUNNING=1 SH_TESTS_USE_SELECT=${{ matrix.use-select }} LANG=${{ matrix.lang }} poetry run coverage run -a -m unittest

Thanks for the hint. I'll play with it and report back.

[1] IIRC, sh is first case with tox.ini file available and supported when running tests using tox is ... unsupported(?); there is/was similar problem with poetry_core, but it looks like they decided to remove support for tox.
[2] We use a bit more complex test setup than that, but that's not important for now.

[mtelka]

It looks like simple unittest testing works properly. That's just python -m unittest. This does require neither poetry, nor coverage. Both looks like unneeded overhead for integration testing needed for my packaging effort.

The move of current tox.ini to tests/tox.ini is probably good idea to avoid future confusion. For my particular case it won't help much because since I already know that the tox testing does not work as I would expect I simply switched to unittest and I no longer care about top-level tox.ini.

[amoffat]

Marking this as closed. If there is any followup discussion please re-open.