Skip to content

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

Closed
wants to merge 37 commits into from

Conversation

andrewleech
Copy link
Contributor

@andrewleech andrewleech commented Mar 17, 2022

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

git rebase -Xtheirs -i --exec 'black --fast --line-length=99 python-stdlib/unittest;git add python-stdlib/unittest; git commit --amend --no-edit' 4c98765e

For now, this keeps it largely in sync with https://pypi.org/project/micropython-unittest/

@stinos
Copy link

stinos commented Mar 17, 2022

Good idea but I wonder whether we need to pull in all those no-code 'release xxx' commits?

@andrewleech
Copy link
Contributor Author

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.

@stinos
Copy link

stinos commented Mar 17, 2022

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?

@andrewleech
Copy link
Contributor Author

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.

andrewleech and others added 26 commits March 18, 2022 09:18
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.
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>
Paul Sokolovsky added 11 commits March 18, 2022 09:18
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>
@andrewleech
Copy link
Contributor Author

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

@mattytrentini
Copy link
Contributor

This looks like it's in good shape - and adds a lot of useful features.

@dpgeorge
Copy link
Member

dpgeorge commented Apr 4, 2022

Closing in favour of #488.

@dpgeorge dpgeorge closed this Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy