testing using micropython lib before deploying to target

[steoj]

As is well known, the micropython library is not implementing all the standard lib functions, and I am trying to write tests using the micropython lib (with its limitations) on my python code before I deploy to target.
I found this interesting thread on testing Micropython, but this focuses mostly on stubbing or replacing u-prefixed libraries and hardware specific modules.

Anyone able to point me to good examples of testing actually including the python-stdlib modules in the micropython libraries?

[glenn20]

If you are mainly interested in testing library and language compatibility issues with Cpython, the unix port is a really easy way to test your micropython code. The unix/windows port runs micropython on your local computer. It doesn't help with testing hardware though.

Where feasible, I also like to build my app code in a modular manner and write tests for each component that makes it easy to deploy those tests onto the board individually before tying it all together into an app. I just use pytest on the computer to deploy and run the component tests on the board.

[glenn20]

...and a plug for the micropython stub library from @Josverl if you use an IDE with a language server to write your code. It provides code completion based on what is actually available in the micropython libraries, rather than the cpython standard library. It is not perfect, but I find it very helpful in alerting me to methods that arent supported by micropython.

[glenn20]

Oh ... and dont forget to check the micropython differences from Cpython docs.

[Josverl]

On stubs:
The micropython stub library also lets you run linters such as PyRight or MyPy in your CI-loop. I would consider this also a test, even if its not pytest.
I recently have done some additional work to further reduce the micropython-stdlib-stubs.
If you have feedback on how/where to improve the stubs, please let me know.

On Micropython-lib:
I've not created stubs directly for micropython-lib, but stubs for any frozen module should be included in the port-board specific stub.
If you see value in stubs for python-ecosys or python-stdlib these could be created, or if you use PyRight for static type checking- it can infer that for you.

On using pytest:
I'm using a mix of 4 options in different projects.

1. Use of Mocking and module replacements in CPython , also allows for some debugging
2. Use of the unix port (no hardware interactions)
3. Use of MPRemote to run simple tests
4. Use of pytest + testbook + Jupyter + Micropython-magics to run more complex tests
5. Use of a Github local runner to run on Actual hardware
6. On some hardware emulators ( to test rp2 PIO applications) of with wokwi esp32 and rp2 emulators

HIL testing:
There was a recent discussion on Hardware In the Loop testing that you may find relevant.

On stdlib:
There is quite a bit of discussion in the CPython communities on what is / is-not / should-not be part of stdlib
it would help to understand what modules you are thinking of.

[stenjo]

Oh, this is useful! Thanks.
More specifically I am trying to modify the datetime module (by extending it) to be able to provide a limited strftime() function. Found out there is a module extending time with this function after having been fiddling with a datetime implementation for a while. I have to look into how to utilize that soon,

Right now I'm stuck in what library to install to be able to test my datetime extension wihout python3 loading the standard datetime implementation instead of the micropython one. How should my test setup look to be able to make it work?

Further down the line, I have to figure out how to run a google-auth authentication and token-handling to be able to port my marquee scroller displaying google calendar events from running on a Raspberry Pi 4 onto an ESP8266 wemos-d1-like thing.

The backdrop of this conversion project is that one of my daughters is now studying electrical engineering at university and has taken an interest in python and electronics. She really enjoys the scroller calendar display, and wants to build one herself. I'm setting up the build-your-own-calendar-display kit at the moment, but replacing the RPi4 with a smaller, more neat device. Nice opportunity to learn some new stuff for me too.

[glenn20]

Right now I'm stuck in what library to install to be able to test my datetime extension wihout python3 loading the standard datetime implementation instead of the micropython one. How should my test setup look to be able to make it work?

If I understand this correctly, you are creating a modified version of the micropython datetime module and trying to get Cpython to load that module so you can test it on your PC, rather than on the micropython board.

That may work up to a point, but there will also be differences in python builtins and internals that mean you will likely continue to run into difficulties usiong this approach. A more reliable approach would be to use the unix port on your PC (or possibly the windows ports, but I believe that is less mature).

[stinos]

Oh, this is useful! Thanks. More specifically I am trying to modify the datetime module (by extending it) to be able to provide a limited strftime() function.

Note there is already a test_datetime.py in micropython's datetime module, though no idea if that actually passes all tests. But worth looking into befoer repeating everything it has.

Anyway: the usual way to go here for something like this which arguably should be CPython-compatible is using the standard unittest module and:

• write tests for the particular thing you'll be implementing, run them using CPython to check that what you'll be implementing matches CPython. So yes that will use CPython's unittest and datetime but that is exactly the point.
• implement your changes to datetime then run the same tests using micropython. Can be any port, but unix or windows ones will just run on your desktop so the cycle is a bit faster. That will use micropython-lib's unittest and datetime modules.
• suppose you want to have a debugger the you'd use CPython but add the path to micropython-lib's datetime module in front of PYTHONPATH to force CPython to use it instead of its own (only an issue for standard libraries - suppose you're testing a module which doesn't exist in CPython and doesn't directly depend on micropython-specific features then the process is similar except that running your tests with CPython will use your module and test it with CPython's unittest module)

[jimmo]

@steoj micropython-lib has a bit of a mix of different approaches to testing... Since the recent improvements to the unittest package there, I thought it would be good to start using it as the default testing method for other micropython-lib modules. e.g. hashlib now uses unittest tests.

(The general idea is to run them on the unix port of MicroPython... running them in CPython can be a bit tricky because many of the packages collide with the built-in names).