Hey!
This is kind of a follow up to our last exchange... I'm honored that you considered my suggestions for implementing only
in Zora but, in the end, I am still not satisfied with the resulting workflow. I'm kind of an intensive user of watch + only with Mocha and I sorely miss not being able to do that in Zora. Even with my own suggested implementation, tending for the only
chain turned out to be a drag...
So I implemented it for myself like I really wanted it. In order to be able to detect only
automatically, I defer execution of top level tests (i.e. harness.test
) until the call to report
. I still want to be able to properly organize my tests, so I've also added a concept of "groups" (inspired from Mocha's describe
) that enables nesting of top level tests. This allows me to use this pattern:
group('foo', () => {
// the group callback is executed synchronously
group('nested', () => {
test('so I am still, in practice, a "top level" test', t => { ... })
test.only('and so I can be auto-onlied!', ...)
})
})
With that, I'm pretty satisfied. And here was born Zorax!
I'm in no way suggesting that you should implement anything like this in Zora. I love Zora being unopinionated and lightweight, so you can implement anything you like on top of it without it getting in the way.
Zorax is entirely built as a set of plugins, that people could use to compose their own custom harness if they want.
To be able to do that, I devised a minimal yet powerful plugin system over Zora. In essence, it automatizes the somewhat tedious and error prone task of wrapping test contexts and nested test contexts, to add extra functionalities (e.g. custom assertions) or override default behaviours.
I extracted this fundamental part as @zorax/plug, because I suspect more people might be interested in the extensibility for their own purposes than my mad scientist assemblage that is Zorax.
I wonder if such a plugin system shouldn't be part of Zora itself... For one thing, I suspect it could probably be implemented in a more efficient way, by adding to prototypes instead of adding to every created test context like I'm currently doing. Secondly, if Zora endorses the plugin system, then everyone's plugins will be compatible between them, instead of being, for example, Zorax-specific. Also, with Zora being so unopinionated, I feel that it would make sense for it to ship with a clear venue for extensibility, as an alternative to superfluous features.
Truly, I don't know... And I am totally satisfied with the current situation, since @zorax/plug
is already available for me to use. But I wanted to offer the suggestion, and I would love to hear your thoughts about this.
Finally, I've seen the pta
project you've started and was excited to try it, but found that integrating a watcher was still pretty rough (remember? watch + only is my kink...). Also, I must say I'm not a big fan of losing the "test is the program" paradigm to the test runner. So I stole you wonderful node reporter (was happy to find it as a standalone package, by the way -- thanks!), and went berserk with building a test runner more aligned with my own priorities. And here was born Zoar!
I mention it in case you're interested in adding a link to these projects in Zora's readme. No worries at all if that's not the case! But I cared to ask because otherwise, considering my general PR skills, they're probably bound to remain 1-user stuff forever ¯\_(ツ)_/¯
I really had a fun time hacking around Zora, and building tests for my hacks with it. Thanks again for your great job!