Looks really nice and clean, though I can't get it to work.

And of course, I love to harp on about the Stepdown rule:

We want the code to read like a top-down narrative. We want every function to
be followed by those at the next level of abstraction so that we can read the
program, descending one level of abstraction at a time as we read down the list
of functions. I call this The Stepdown Rule.

To say this differently, we want to be able to read the program as though it
were a set of TO paragraphs, each of which is describing the current level of
abstraction and referencing subsequent TO paragraphs at the next level down.

To include the setups and teardowns, we include setups, then we include the
test page content, and then we include the teardowns.

To include the setups, we include the suite setup if this is a suite, then we
include the regular setup.

To include the suite setup, we search the parent hierarchy for the
"SuiteSetUp" page and add an include statement with the path of that page.

To search the parent...

It turns out to be very difficult for programmers to learn to follow this rule
and write functions that stay at a single level of abstraction. But learning
this trick is also very important. It is the key to keeping functions short and
making sure they do "one thing." Making the code read like a top-down set of
TO paragraphs is an effective technique for keeping the abstraction level
consistent.

I know it's not easy to use it consistently in a non-compiled language like Python, but I like to follow it whenever I can.

Still not 100% happy about the stepdown order, but it does the trick :-D

If you come up with a feasible testing strategy, a PR for that would be welcome, of course!