Hi Andrey,
thanks for sharing your thoughts.
On 08.12.20 21:43, Andrey Rahmatullin wrote:
You didn't explain what actual problems do you have, but
https://github.com/lark-parser/lark/issues/792 suggests that some way you
used was skipping some of the tests?
I am not familiar enough with Python unit testing for a solid judgement
but I find it disturbing that the outcome of the test suite depends on
the way you run it. I wonder whether this is
a) due to a problem in the test suite,
b) due to a problem somewhere in the tested code,
c) by construction because the three different ways to run the test
suite are not equivalent?
Upstream uses option 3 in its CI testing [2] and did not see any issues with
lark release 0.11.1. dh_auto_test seems to use option 2 by default (for the
pybuild build system). For autopkgtest I have chosen to use option 1. The
latter two options both fail for version 0.11.1.
Which is good?
After applying a patch provided by upstream [3], also option 2 works but option
1 still fails.
Which is good or bad? I'm not sure.
I am asking myself the same questions. That is why I am asking for
advice here. :-)
Upstream suggested to change the way the (autopkgtest) tests are run [4].
So are you asking only about autopkgtests, not build-time tests?
Rereading it I think one should not constrain the question to
autopkgtests but also consider build-time tests.
Is there something like a general recommendation on what is the best way
to run Python unit tests?
No (except "whatever the upstream CI runs").
This would vote for option 3:
pythonX -m tests
Best regards
Peter
