[matt_trentini]

Unit test coverage is exceptionally high for the interpreter, and always has been:

https://micropython.org/resources/code-coverage/

('py' folder: 99.2% line, 88.7% branch coverage)

Testing the port-specific code has been a much more challenging problem.

Which is why in the past year or two there's been a lot of energy put in to HIL testing. There are now a few dozen boards that are automatically tested with an increasingly rich suite of hardware tests. Both the number of boards and tests are increasing rapidly.

It's not perfect but it's getting pretty darn good. If you want to help out please do reach out.

[xchip]

Then why do they have 1300 issues open? Good luck to you but it looks like a land mine to me. They are 420 pull requests not merged, so that is a lot of disappointed developers.

They need to test the whole ecosystem, that is the usual interaction with typical peripherals (I2C, I2S, SPI, Serial, interrupts...) and for every bug fixed there should be a unit test to make sure future changes don't cause regressions.

I had this conversation with them but they take every opportunity to justify/ask for more funding.

They are also prioritizing adding support for new chips but they quickly get eaten alive by chaos, regressions and platform fragmentation.

[matt_trentini]

> Then why do they have 1300 issues open? There are 420 pull requests not merged...

Because it's a large, widely-used project with relatively few core developers. Many other projects have similar numbers of issues, that's not unique to MicroPython! For example, I admire Zephyr's organisation, yet they have double the issues and 5x the PRs.

> They need to test the whole ecosystem...and for every bug fixed there should be a unit test...

Sure, that's a great ideal to strive for. That was - and is - the case for the language and interpreter. It's becoming more common for port-specific code as the tools to allow automated hardware testing are implemented. But it doesn't happen overnight and it's a large surface area.

> I had this conversation with them but they take every opportunity to justify/ask for more funding.

Ah, I presume you're referring to this discussion?

https://github.com/orgs/micropython/discussions/13436

No-one asked for funding. Some noted that such testing infrastructure doesn't come without effort or for free.

BTW I'm not sure if that was you, but that post had a pretty unhelpful, disrespectful tone. If that was you, I suggest you check your tone and get in and help create some tests. We'd appreciate the help!

> They are also prioritizing adding support for new chips...

That's often paid work. Recent paid work has helped fund HIL testing. Further, a careful expansion of the number of ports is necessary to avoid becoming irrelevant.

> ...get eaten alive by chaos, regressions and platform fragmentation

I use MicroPython commercially, daily...and I don't share your experience with chaos or regressions. Sure, sometimes issues occur, particularly if you're on the bleeding edge - but they're pretty well controlled and rapidly fixed. YMMV.

As for platform fragmentation, I struggle to understand your concerns; it has been improving for a long time now as developers have focused on ensuring compatibility between ports. Again, yes, there are some differences - but given how radically different the micros can behave, the consistency between ports is pretty remarkable.

[xchip]

>testing infrastructure doesn't come without effort or for free.

We don't implement unit tests because it is more effort, we implement them because in the long run is less effort and we catch issues before they happen.

Up to you.