-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Unittest updates from pycopy #487
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
Conversation
Good idea but I wonder whether we need to pull in all those no-code 'release xxx' commits? |
Yeah I probably should have marked this pr as draft as I haven't reviewed all the changes myself yet. This was intended as a first step in a series of updates I have planned for unittest in the coming days; there's some bugs relating to test error handling / reporting then I want to add an implementation of https://docs.python.org/3/library/unittest.html#test-discovery Before I went to far into that I wanted to check what had already been done on the other fork; turns out some of it was things I'd submitted myself back in the day. On a more specific note though, even those version commits are making changes in the sense they're updating the reported version. While these changes are in sync with what happens to be on pypi I feel it makes sense to keep the version numbers in sync too? Once features diverge, then it's a different story. |
The idea of versions (as I perceive it begin used here) if to bump them to get new pypi packages indeed. So in this case I'd go for a bunch of commits improving unittest, then one single commit bumping version? |
Very true, the version updates are to push to pypi - which we can't do for this package here because the pypi name is already taken. That's a separate issue to deal with elsewhere though. I'll review the rest of the changes here tomorrow either way - if some of them don't make sense to keep then I'll probably strip down / reorder everything here. However if everything looks relevant and worthwhile then I think it's less confusing to anyone coming back and comparing the two forks in the future; the more they match match commit by commit (within a particular package at least) the easier it is to review. |
Store traceback details for each test failure and log to console at the end of the test, like CPython version of the module does.
Without this change, current implementaiton produces a false positive result for AssertionError type. Example of falsely passing test code: def test(a, b): assert a > 10 assert b > 10 self.assertRaises(AssertionError, test, 20, 20)
Make sure that not raising AssertionError from tested function is properly caught.
For tests to check. This feature is used by CPython stdlib tests.
As used by CPython testsuite.
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
To avoid possible name clashes. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
And for clarity, rename runner function run_class() -> run_suite(). Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Mostly to workaround inherited MicroPython's issues with inheritance. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Just runs "subtests" in the scope of the main TestCase. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
For CPython compatibility. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Also, rework result printing to be more compatible with CPython. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Perhaps, modern CPython (3.8). Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
For CPython compatibility. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
E.g. for doctest. Signed-off-by: Paul Sokolovsky <pfalcon@users.sourceforge.net>
1cadcff
to
f6ad093
Compare
The initial branch I pushed had some rebase errors which have now been fixed. I went through the commits one by one and I think all the code changes make sense and generally improve the compatibility with cpython/unittest. I've continued to build new features on top of this branch in #488 |
This looks like it's in good shape - and adds a lot of useful features. |
Closing in favour of #488. |
The unittest library has had a number of quality-of-life improvements from a couple of contributors on the pycopy fork of micropython-lib.
This PR cherry picks / rebases them on current master, with black run over each commit interactivly, eg
For now, this keeps it largely in sync with https://pypi.org/project/micropython-unittest/