Bootstrap python tests #697
Conversation
…a/pyscript into fpliger/663_bootstrap_py_tests_2
There was a problem hiding this comment.
Thanks for adding these @fpliger!
I'm curious about these two Mock files you added, but other than that LGMT.
| """Mock module that emulates some of the pyodide js module features for the sake of tests""" | ||
| from unittest.mock import Mock | ||
|
|
||
| document = Mock() | ||
| console = Mock() |
There was a problem hiding this comment.
I don't understand what this code is for (same for the micropip.py file).
The other parts of tests we're using console are here for example:
<py-script>import js; js.console.info('one')</py-script>
<py-script>js.console.info('two')</py-script>
<py-script>js.console.info('three')</py-script>
<py-script>js.console.info('four')</py-script>
But it's not using this object, as far as I understand.
Can you please explain it?
Thanks!
There was a problem hiding this comment.
There are fixtures for the the apis that are pyodide specific. The tests/integration tests run a web server that actually run the code in pyodide while the python tests are actually running python unit tests in local python. So the js and micropip modules are not there. We can potentially think of running the tests in pyodide at some point but even then, I think it makes sense for us to mock their API to make sure that we are calling them correctly...
In general, we'll be supporting other runtimes that are not pyodide so I think that it's important that we decouple our Python higher level API and test the interface itself.
Makes sense?
(given your comment, I think it actually makes sense for us to put js.py and micropip.py in a fixtures folder but we can do it in a separate follow up PR.
There was a problem hiding this comment.
Makes total sense =)
Thanks for the explanation.
Close #617
Supersede #665