-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
tests/run-tests.py: Change --target/--device options to --test-instance. #16111
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
tests/run-tests.py: Change --target/--device options to --test-instance. #16111
Conversation
@stinos FYI |
Code size report:
|
5979b7d
to
4f6e371
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #16111 +/- ##
=======================================
Coverage 98.57% 98.57%
=======================================
Files 164 164
Lines 21345 21345
=======================================
Hits 21041 21041
Misses 304 304 ☔ View full report in Codecov by Sentry. |
This looks amazing @dpgeorge I'm a huge supporter of automating testing like this in hardware! It should make it much easier for myself and other developers to run these tests, which lowers the barriers to extending them and creating new ones to improve test coverage! @mattytrentini @Josverl @hmaerki this could integrate nicely into a chain with mpbuild, mpflash and octoprobe |
@andrewleech This is not the full auto test runner yet 😄 Just the first small piece. |
4f6e371
to
bd7a336
Compare
Actually, this could possibly be an issue in some corner cases, eg when you want to use the "minimal" target profile on a non-minimal port, say zephyr (that's what the CI used to do). But I'd rather solve that problem by doing better auto-detection of features that the port has, rather than needing to specify it on the command line. So I still stick with this PR and the fact you can no longer specify the platform, it's always taken from |
bd7a336
to
1424f23
Compare
See #16112 for that. |
Octoprobe will provide everything to make it fully automated, even as self-hosted github runner - let me first finish the documentation. |
@@ -115,6 +200,53 @@ def convert_regex_escapes(line): | |||
return bytes("".join(cs), "utf8") | |||
|
|||
|
|||
def get_test_instance(test_instance, baudrate, user, password): | |||
if test_instance.startswith("port:"): |
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's not really clear to me where/how this can be specified, should this be in the help (-h) output?
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.
Ah, I missed documenting this. Now added to the help text.
This looks good. Since for the default (running with unix port and/or using MICROPY_MICROPYTHON) nothing changes, it might be clearer if the commit mentions that explicitly. |
@hmaerki I mixed up this PR with another one, take a look at: #16112 |
1424f23
to
600162a
Compare
Commit message now updated to mention that. Also I embellished the help text further to explain more about the |
Ok, nice. |
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.
One small comment, but this looks good to me. Yay for improved ergonomics!
tests/run-tests.py
Outdated
If a test fails, run-tests.py produces a pair of <test>.out and <test>.exp files in the result | ||
directory with the MicroPython output and the expectations, respectively. | ||
""", | ||
epilog="""\ | ||
The -t option accepts the following for the test instance: | ||
- micropython - use the unix port of MicroPython, specified by the |
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.
This is a bit nitpicky, but how about naming this option unix
?
(In a follow-up, I'd be interested to add support for unix:<VARIANT>
to cut down on environment variable wrangling when testing minimal
or coverage
variants.)
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.
This was called "micropython" to match run-multitests.py
(and eg to distinguish from "cpython" possibility in the multitests).
But, happy to change it to "unix" here. That makes more sense, especially if you can also select "webassembly" as an option.
Eventually we can update run-multitests.py
to use the same conventions (and even provide "micropython" as a backwards-compatible alias to "unix" there).
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.
Oh, and the current (on master) target for the unix port is actually "unix"! And is actually the default value for --target
. So makes sense to keep it as "unix".
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.
Changed "micropython" to "unix".
Signed-off-by: Damien George <damien@micropython.org>
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>
Signed-off-by: Damien George <damien@micropython.org>
698f5fb
to
85053ad
Compare
Summary
Previously to this PR, running the test suite on a bare-metal board required specifying the target (really platform) and device, eg:
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:There are also some shortcuts to specify a port/device, following
mpremote
:For example:
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.
Testing
Ran the tests on a Pico and ESP8266 to verify it still works as expected. Also CI for this PR will test a lot of things (unix, webassembly, qemu, zephyr).
Trade-offs and Alternatives
One can no longer specify the platform (eg unix, pyboard, rp2, etc), it's now always automatically detected. I don't think this is an issue.
The new argument is
--test-instance
with-t
for short. It could be--target
or--dut
or something else, but I think--test-instance
captures the intent pretty well.Eventually this scheme would be adopted by the other test runner scripts like
run-multitests.py
andrun-perfbench.py
.