8978102f35
Previously to this commit, running the test suite on a bare-metal board
required specifying the target (really platform) and device, eg:
$ ./run-tests.py --target pyboard --device /dev/ttyACM1
That's quite a lot to type, and you also need to know what the target
platform is, when a lot of the time you either don't care or it doesn't
matter.
This commit makes it easier to run the tests by replacing both of these
options with a single `--test-instance` (`-t` for short) option. That
option specifies the executable/port/device to test. Then the target
platform is automatically detected.
The `--test-instance` can be passed:
- "unix" (the default) to use the unix version of MicroPython
- "webassembly" to test the webassembly port
- anything else is considered a port/device to pass to Pyboard
There are also some shortcuts to specify a port/device, following
`mpremote`:
- a<n> is short for /dev/ttyACM<n>
- u<n> is short for /dev/ttyUSB<n>
- c<n> is short for COM<n>
For example:
$ ./run-tests.py -t a1
Note that the default test instance is "unix" and so this commit does not
change the standard way to run tests on the unix port, by just doing
`./run-tests.py`.
As part of this change, the platform (and it's native architecture if it
supports importing native .mpy files) is show at the start of the test run.
Signed-off-by: Damien George <damien@micropython.org>
70 lines
1.8 KiB
ReStructuredText
70 lines
1.8 KiB
ReStructuredText
.. _writingtests:
|
|
|
|
Writing tests
|
|
=============
|
|
|
|
Tests in MicroPython are located at the path ``tests/``. The following is a listing of
|
|
key directories and the run-tests.py runner script:
|
|
|
|
.. code-block:: bash
|
|
|
|
.
|
|
├── basics
|
|
├── extmod
|
|
├── float
|
|
├── micropython
|
|
├── run-tests.py
|
|
...
|
|
|
|
There are subfolders maintained to categorize the tests. Add a test by creating a new file in one of the
|
|
existing folders or in a new folder. It's also possible to make custom tests outside this tests folder,
|
|
which would be recommended for a custom port.
|
|
|
|
For example, add the following code in a file ``print.py`` in the ``tests/unix/`` subdirectory:
|
|
|
|
.. code-block:: python
|
|
|
|
def print_one():
|
|
print(1)
|
|
|
|
print_one()
|
|
|
|
If you run your tests, this test should appear in the test output:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ cd ports/unix
|
|
$ make tests
|
|
skip unix/extra_coverage.py
|
|
pass unix/ffi_callback.py
|
|
pass unix/ffi_float.py
|
|
pass unix/ffi_float2.py
|
|
pass unix/print.py
|
|
pass unix/time.py
|
|
pass unix/time2.py
|
|
|
|
Tests are run by comparing the output from the test target against the output from CPython.
|
|
So any test should use print statements to indicate test results.
|
|
|
|
For tests that can't be compared to CPython (i.e. micropython-specific functionality),
|
|
you can provide a ``.py.exp`` file which will be used as the truth for comparison.
|
|
|
|
The other way to run tests, which is useful when running on targets other than the Unix port, is:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ cd tests
|
|
$ ./run-tests.py
|
|
|
|
Then to run on a board:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ ./run-tests.py -t /dev/ttyACM0
|
|
|
|
And to run only a certain set of tests (eg a directory):
|
|
|
|
.. code-block:: bash
|
|
|
|
$ ./run-tests.py -d basics
|
|
$ ./run-tests.py float/builtin*.py
|