-
-
Notifications
You must be signed in to change notification settings - Fork 863
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
Experimental new test system #1047
Conversation
mypy is failing due to the horrible hack to expose run_code. An even worse option would be to add it to builtins, but that still doesn't make mypy happy |
New error log:
The line number and file name are now accurate |
This partially addresses #1031 |
Thanks Dexter! This looks fantastic! pyodide.runPython(`
<ctrl+v>
`) and run the test without having to completely rearrange it. Maybe we should add a |
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.
It would certainly be great to be able to do this!
conftest.py
Outdated
@@ -455,6 +458,57 @@ def service_actions(): | |||
httpd.serve_forever() | |||
|
|||
|
|||
def run_in_pyodide(*args): | |||
# This can be called as @run_in_pyodide or @run_in_pyodide("first_dep", | |||
# "second_dep"). In the former case, run_in_pyodide acts as the decorator. |
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.
If it can only be called with the second variant and it allow to simplify that's also fine.
I have squashed and force-pushed because I rewrote a huge chunk of it and moved it to a different file, so the diffs won't be very useful either way. |
This introduces a new way of writing tests via the decorator @run_in_pyodide. This runs the entire decorated function via selenium.run, and passes on any error.
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.
Thanks mostly looks good. Minor comments below.
Also,
- I'm fairly surprised that using a decorator defining an internal function with a pytest fixture works. Could we find some reference on whether it's expected to work, or if this is relying on some internal implementation detail of pytest which can be broken at any time.
- just curious would adding
@pytest.mark.parametrize
, before or after, work (or could be made to work -- though not in in this PR)?
packages/jedi/test_jedi.py
Outdated
""" | ||
) | ||
assert result == ["load", "loads"] | ||
from tools.testing import run_in_pyodide |
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.
Tools is not really a place for python modules. I would rather we put it in pyodide_build
. I mean it's called build, but in practice it's anything that shouldn't be included in WASM VM (build, testing, etc). So can also rename it to be more general.
Among other things mypy and pytest are not currently run on the tools
folder.
tools/testing.py
Outdated
catches the function the decorator is applied to. Otherewise, standalone | ||
and packages are the actual arguments to the decorator. | ||
|
||
See docs/testing.md for details on how to use this |
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.
Please document parameters in the docstring still and ideally add type annotations.
I would expect fixtures to work by querying the parameter names, e.g. via inspect. This should work with dynamically generated functions. |
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.
Thanks!
This introduces a new way of writing tests via the decorator @pytest.run_code. This runs the entire decorated function via selenium.run, and passes on any error.
Nothing in here is intended to be final. For example, there ought to be a better way to expose run_code to the tests. Comments welcome.
This also produces more legible errors, e.g. if I change the code to simply assert False, I get