Hmm.. They really expect an inherently different behavior.

What should we do in such case? Is there any option to run tests based on external reading of mpconfig.h? If not, then perhaps we should add a ussl.backend resolving to axtls or mbedtls, then the test run only the relevant cases based on the implementation.

Btw, this partly stems the same problem as I've described in #4475.

That test is just a hack.

then perhaps we should add a ussl.backend

Adding more bytes is not allowed ;-). (Well, in coverage build, everything is allowed).

In the CI, run-tests uses the coverage build? If so, I can add a MICROPY_PY_USSL_BACKEND thing, enabled only for coverage.

Well, as I told, that test is hack. Patching it with even more hacks unlikely seems like a good investment of effort.

Instead imagine how a real test would be written: allow to override time and random sources for the underlying TLS lib, then feed predefined/read expected TLS records. Well, could also implement real TLS handling on the tester side ;-).

If it doesn't do that, it's a hack. And if some lines of a hack doesn't work with different TLS implementations, those lines are very bad hack. Their removal is obvious solution. Well, could also keep them in a dirty attempt to keep coverage, just test for variants of expected behavior explicitly (not by printing stuff).

Note that #4481 was posted also as an example that adding any adhoc, mis-leveled tests (which test not TLS, but low-levelish, corner behavior of current implementations) would only complicate matters.

Fixed by 18ecc29