-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
cpydiff: Fix test case for json_nonserializable. #16140
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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #16140 +/- ##
=======================================
Coverage 98.57% 98.57%
=======================================
Files 164 164
Lines 21345 21345
=======================================
+ Hits 21040 21041 +1
+ Misses 305 304 -1 ☔ View full report in Codecov by Sentry. |
7226a7b to
fc729b9
Compare
| x = json.loads(z) | ||
| print("Should not get here") | ||
| z = json.dumps(json) | ||
| print("Produced non-conforming json string", repr(z)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the original test was testing that bytes are not serialisable, which would be more of a subtle difference between CPython and MicroPython than trying to serialise a module.
Suggest to simply do:
try:
print(json.dumps(b"shouldn't be able to serialise this")
except TypeError:
print("TypeError")The test case was producing the following error: ``` Traceback (most recent call last): File "<stdin>", line 12, in <module> UnicodeError: ``` which did not demonstrate the intended difference. (this particular non-json-serializable object DID throw an exception! just not TypeError) The updated test uses a byte string with all ASCII bytes inside, which better illustrates the diference. Signed-off-by: Jeff Epler <jepler@gmail.com>
fc729b9 to
5016780
Compare
|
Updated... |
|
There are CI errors but they appear unrelated to this change. -- /home/runner/work/micropython/micropython/tests/results/thread_thread_lock4.py.exp 2024-11-07 16:44:53.393277488 +0000
+++ /home/runner/work/micropython/micropython/tests/results/thread_thread_lock4.py.out 2024-11-07 16:44:53.393277488 +0000
@@ -58,3 +58,4 @@
77 145183092028285869634070784086308284983740379224208358846781574688061991349156420080065207861248000000000000000000
78 11324281178206297831457521158732046228731749579488251990048962825668835325234200766245086213177344000000000000000000
79 894618213078297528685144171539831652069808216779571907213868063227837990693501860533361810841010176000000000000000000
+CRASH
\ No newline at end of file
FAILURE /home/runner/work/micropython/micropython/tests/results/thread_thread_lock4.py--- /home/runner/work/micropython/micropython/tests/results/extmod_time_time_ns.py.exp 2024-11-07 16:44:35.601734727 +0000
+++ /home/runner/work/micropython/micropython/tests/results/extmod_time_time_ns.py.out 2024-11-07 16:44:35.601734727 +0000
@@ -4,7 +4,7 @@
True
True
True
-True
+False
True
True
True
FAILURE /home/runner/work/micropython/micropython/tests/results/extmod_time_time_ns.py |
|
I reran the failing CI and now it passes. |
|
Rebased and merged in 3844733 |

The test case was producing the following error:
which did not demonstrate the intended difference. (this particular non-json-serializable object DID throw an exception! just not TypeError)
The updated version creates the non-conforming json string
"<module 'json'>"instead, better illustrating the problem.I tested by manually running the example using a coverage build & in cpython.