The Colmi P8, which is older, long replaced by myriads of newer china watches and now hard to even find, was one of the last cheap smartwatches to be based on the nRF52832 microcontroller/SOC which had the advantage (for that purpose) of being both well documented and yet not locked down. The successor SOC, the nRF52840, already had a flash securing feature that (except for devices that wouldn't use it or that would have exploitable vulns) made it easy for the manufacturer to lock the device down and to prevent the install of alternative firmwares. Also about that time, cheaper chinese SOCs came out and cheapo china smartwatches switched to using those instead of nRF. Trouble being: most of those chinese SOCs for smartwatches, aside from probably also having the lockdown problem, don't have much in terms of openly accessible documentation or developer tools.
Consequently, pretty much all open source projects for cheapo china smartwatches apparently only support devices that are so old that you don't even find them anymore on aliexpress or other such shops.
I'd be interested to know for what currently easily available cheap (i.e. not in a much higher price category) china smart watches there is an open source alternative firmware that does not miss half of the features.
I’ve started playing with esp32/rp2350 based boards that have everything in the same form factor. The only thing missing is a fully waterproof enclosure (they expose the back pcb). And vibration motor.
that could indeed be an option depending on your use case. The problem with those (aside from finding a suitable enclosure) is that while more powerful, they aren't at all optimized for use in really low-power conditions and that their energy consumption is consequently enormously higher than that of e.g. an nRF52 (e.g. nRF52832 or nRF52840), so that the battery time would likely be significantly shorter.
Regarding power I agree - a weeks worth is hard to get. inside i don’t mind plugging in power and outside if a lipo battery can last afew hours (while jogging etc) I’m good to go. Also these cpus have very good sleep modes.
The sys.monitoring and import optimisation suggestions apply as-is.
If you use standard unittest discovery the third item might apply as well, though probably not to the same degree.
I don’t think unittest has any support for distribution so the xdist stuff is a no.
On the other hand you could use unit test as the API with Pytest as your test runner. Then you can also use xdist. And eventually migrate to the Pytest test api because it’s so much better.
I wwsn't familiar with this sys.monitoring option for coverage. Going to give it a try in my test suite. At the moment with docker testcontainers, gh actions test matrix for multiple python versions, and unit + regression + integration tests it is taking about 3-5 minutes.
Warning, there is a change in coverage 7.7.0 that disables sysmon support for coverage if using branch coverage _and_ a version of Python before 3.14alpha6.
I profiled a huge legacy tests collection using cProfile, and found lots of low hanging fruits. Like some tests were creating 4000x3000 Pillow image in memory just to test how image saving code works (checkign that filename and extension are correct). And hundreds of tests had created this huge image for every test (in the setUp method) because of unittest reliance on inheritance. Reducing size image to 10x5 made the test suite faster for like 5-7% (it was long time ago, so I don't remember exact statistics).
But the changes in TFA were of the other of 75% improvement for "dumb" changes that were agnostic to the details of the tests being run.
Saying you got a 5-7% improvement from a single change, discovered using the profiler, that took understanding of the test suite and the domain to establish it was OK, and that actually changed the functionality under test - that's all an argument for doing exactly the opposite of what you recommend.
> that actually changed the functionality under test - that's all an argument for doing exactly the opposite of what you recommend.
It was an old functionality. Someone wrote a super class that for the need of testing filesystem functionality created extremely large images. Not only there was no need to test with such large images, other developers eventually inherited more testcases from that setup code (because there were other utility methods), and now setUp code was needlessly creating images that no test used.
Generating a huge 4k image takes a significant time using Pillow.
The sandbox is a lightweight Alpine-based container, it runs as a non-root user for security, it has minimal dependencies installed (curl, bash, coreutils)
The container has restricted outbound access—only HTTP/S requests are allowed. It runs inside an isolated network namespace with no access to the host network or other infrastructure components. There's no inbound access, and the container can't receive unsolicited requests from the outside world.
The sandbox container can only communicate with other containers in the same network, the main application container and sandbox container are on the same network, allowing them to communicate.
