On Mon, Jul 29, 2024 at 3:32 PM Han-Wen Nienhuys <hanw...@gmail.com> wrote:

> On Mon, Jul 29, 2024 at 12:10 PM Luca Fascione <l.fasci...@gmail.com>
> wrote:
> > So once you have the above, you add hierarchies to the above so you can
> deploy a branch-and-bound strategy
> >
> > Make bigger tests that check several things at once (these are probably
> approximately the tests you have now, I suspect)
> > These will fail using much tighter acceptance criteria (if they pass
> you're very sure it's all good)
> > When these "supertests" fail, the inner tests they cover are run, and a
> report is made containing the outcome of those
> > When these "supertests" pass, the inner tests are skipped: this is where
> you get major time savings
>
> On the contrary: these are all extra invocations that need to be
> coordinated. To make things go fast, you want to run lilypond once on
> a ton of files, so it can use parallelism to blaze through all of
> them.
>

Or you run it "horizontally":
think of your tests as a tree, and do a breadth-first traversal.
In doing this you run all tests on the current depth as a single invocation
of lilypond.
This way you run it once on one "giantmegathing" (which may well not exist).
If this is identical, you're done.
Else you run it on 15 things, if these pass, you write a small report
Else you run it on -> more than likely maybe 50 things: because it won't be
the case that all your partitions fails,
chances are high on a couple will
And so on.
If each test splits 10way, you'd run lilypond "no more than 4 times"
(with caveats that should be obvious: test tree won't be perfectly balanced
and all that)

I do realize this is some retooling of the regtest infra,
I'm just saying, it'd be a way to test more, and in a potentially more
capillary way
than what we have now.

L


-- 
Luca Fascione

Reply via email to