Feature Request: Allow `*run()` generators?

[Zearin]

From my journey learning to use hTest in #100, I’m trying to convert some pretty basic Web Platform Tests into hTest in order to learn how to write things hTest-style.

Although the flexibility of the test syntax means there’s probably an alternative way to write this, what my brain wants to do is something like this:

// …
{
    data: { 
        constructors: [ DOMRect, DOMRectReadOnly ]
    },

    *run(...args) {
        for (const ctr of this.data.constructors) {
            yield new ctr(...args)
        }
    },

    tests: [ … ]
}

I know that as soon as async arrived, everyone wanted to ditch generators and make everything async.

Although I haven’t personally written an async generator, Dr. Axel’s (of 2ality fame) chapter on Async Iteration from Exploring Javascript makes it clear that generators and async are orthogonal.

That makes sense to me, so even without firsthand experience (beyond surface level), my brain likes to keep the concepts separate, rather than overwriting all generators with async functions.

✅ hTest already has async support out of the box.

❓ Is it feasible to allow generators for run() functions, too?

[LeaVerou]

Oh that's an interesting idea. How would it work exactly?

[Zearin]

I just figured that each yield-ed value would be passed to the tests…?

(Maybe there’s a good reason this wouldn’t work. I’m no wizard, I just enjoy working with code. ☻)

[LeaVerou]

I mean, would it run all descendant tests before getting the next value or would it run each test for all values and then go to the next value?

[Zearin]

Good question. 🤔 This is the sort of thing I didn’t think about beforehand!

I could just pick one, but that’s not a great plan when there might be big implications for other users.

Maybe this shouldn’t overload run(), in that case.

• Perhaps a different function? (i.e. *runIter(). There’s probably a better name, I just wrote the first thing that came to mind.)
• Perhaps an option like {iter: 'depth-first'} or {iter: 'breadth-first'} (like directory traversal)?
  • (💭More thinking aloud) Hmm…Iteration ≠ Generators. The name should probably not mislead people into thinking it applies to any iteration, if the implementation is going to be generator-specific.
  • Maybe this is a good case for an hTest API where you call a function with options, and it returns a function that returns the appropriate implementation.

Do any of those sound feasible?

[LeaVerou]

I think the bigger picture pain point of having a list of Ms and a list of Ns and you want to test any (m, n) pair is a very valid one. You can do it today imperatively, by generating the corresponding objects:

tests: constructors.map(ctr => ({
	run(...args) {
		return new ctr(...args)
	},
	tests: [ /* ... */ ]
}))

but I can see how a fully declarative solution may be desirable. Let me think about it some more. 🤔

[LeaVerou]

I just ran into this myself when I wanted to test two things for the same value: both properties of the value itself, but also that it was of a specific type.