miyuchina / mistletoe

A fast, extensible and spec-compliant Markdown parser in pure Python.
MIT License
811 stars 113 forks source link

`tox.ini` is missing testing configuration #220

Closed mtelka closed 1 month ago

mtelka commented 1 month ago

The tox.ini file is missing testing configuration so tox does basically nothing on invocation. Adding this to tox.ini solves the issue:

[testenv]
commands =
    python -m pytest {posargs}
pbodnar commented 1 month ago

@mtelka, thanks for the tip. I feel like there are tens of ways and tools for setting up a Python project and I kinda refuse to study them all. ;P So do you think you could explain what is the advantage of defining and/or running tests with it? Is it the commands section which gets executed when somehow creating a given environment (testenv) in your example?

Another thing is that mistletoe historically uses unittest and is ready to run them via make (see its makefile). Yet we've introduced pytest for GitHub workflow actions, so another inconsistency...

PS: Of course, PRs are also welcome. ;)

mtelka commented 1 month ago

From https://tox.wiki/: tox aims to automate and standardize testing in Python.

It means that when there is tox.ini file available then it is reasonable to expect that tox will be able to run tests.

In my case I package Python projects for OpenIndiana and during the packaging I need to run tests to make sure the package is working properly on our (not so common) operating system. To make things as easy as possible I try to automate everything, including the testing.

The first step to run tests automatically is a detection how to run tests. To do so the tox -l command is started and when it pass it means the tox is supported and so then used to run tests using the well known commands (like tox -e py39). And here is the problem: since there is missing the actual testing configuration in the tox.ini file the command just (silently) does nothing:

$ tox -e py39
.pkg: install_requires> python -I -m pip install 'setuptools>=40.8.0' wheel
.pkg: _optional_hooks> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
.pkg: get_requires_for_build_sdist> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
.pkg: get_requires_for_build_wheel> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
.pkg: install_requires_for_build_wheel> python -I -m pip install wheel
.pkg: prepare_metadata_for_build_wheel> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
.pkg: build_sdist> python /usr/lib/python3.9/vendor-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
py39: install_package> python -I -m pip install --force-reinstall --no-deps /tmp/test/mistletoe-1.4.0/.tox/.tmp/package/1/mistletoe-1.4.0.tar.gz
  py39: OK (7.78 seconds)
  congratulations :) (8.12 seconds)
$

Because of this I cannot rely on our automatic tooling for mistletoe and I need to do some manual work and use a non-default config (in this case a patch) to make everything working as expected and designed.

Makefiles are rarely used for Python projects. For similar tasks you use the makefile for (coverage, benchmarks, docs, etc.) people often use tox too. But this is a bit off-topic here.

If you prefer to use unittest to run tests then you can use something like:

[testenv]
commands =
    python -m unittest {posargs}

or maybe even:

[testenv]
commands =
    python -m unittest {posargs:--verbose}

to make the test report verbose by default.