On Fri, Jan 17, 2025 at 08:35:42PM -0800, Simon Glass wrote:
[snip]
At present 'ut all' fails so I am going to take a look at that. Quite a bit of clean-up needed in test system, though. Ideally we could run the tests in random order so we can find and fix the dependencies. For driver model we reinit as needed, but that's not the case for EFI, for example.
Personally, for making pytest faster I'd look at the general recommendations various blog posts about "make your pytest run faster" and then go from there.
I think the problem is that you are looking at the C tests through a Python lens, so everything seems a bit slow.
'ut all' takes about 18 seconds for me.
Yes, and the "ut" tests just via pytest do take longer. And it would be good to have more testing in CI, and for tests to be as fast as possible.
Looking at the run I just did on HW: ====================== 202 passed, 426 skipped in 48.76s ======================= ================= 202 passed, 426 skipped in 80.04s (0:01:20) ================== ================= 206 passed, 422 skipped in 128.74s (0:02:08) ================= ================= 206 passed, 422 skipped in 118.15s (0:01:58) ================= ================= 206 passed, 422 skipped in 128.65s (0:02:08) ================= ================= 206 passed, 422 skipped in 123.76s (0:02:03) ================= ================= 205 passed, 423 skipped in 128.22s (0:02:08) ================= ================= 198 passed, 429 skipped in 106.92s (0:01:46) ================= ================= 192 passed, 431 skipped in 87.95s (0:01:27) ==================
That could be better, but it's not unreasonable and part of that is tftp'ing an 83MB kernel image.
I think if I had a point around here before, it was this. C is a terrible language for processing strings. Python is a reasonable language for processing strings. Neither of these statements should be controversial. The controversy is that I'm saying tests that parse output for results shouldn't be written in C.