Feature wise, I’m not sure what’s new here. Popular BDD style JS test runners/frameworks like Jasmine, Jest (IIRC delegates to Jasmine by default, though that’s swappable), Ava (custom built test runner), can all be configured, more or more. Some of the tools require you to bring-your-own-TypeScript, some don’t offer parallelization, but those are just general features that are not coupled to this pitch of being configurable.<p>With relatively straightforward “refactoring” and functional programming patterns, the aforementioned mainstream test runners/frameworks can provide the same ergonomics as Folio. Folio then is just an opinionated interface for specifying parameterized configurations on top of a test runner. Functional programming with higher order functions is powerful and not necessarily require more than a screen’s worth of custom code either. I’m not sure the ergonomic abstractions offered by Folio is worth adopting a new test runner versus defining your own abstraction on top of existing battle hardened test runners ( test frameworks are already the abstraction on top of test runners, with test runners be analogous to React just being a library. Jest sits on top of Jasmine by default, but you can swap that out ). This is like adopting a new Linux distro that decided to roll its own non-Linux kernel.<p>Edit: ah, I see, this is a project out of Microsoft versus some rando JS developer bloating the ecosystem to pad their resumes and spend more time wordsmithing/branding than actually building something novel. From an org perspective, I empathize a bit with the not-invented-here syndrome then, especially since Facebook leads Jest development<p>Edit 2: I think it would be more appealing to market this as a TypeScript-as-a-first-class-citizen test framework that has the backing of a reputable org with resources. TypeScript flavors of Ava or Jest are after-market forks with an order magnitude less support / community / maintenance, meaning you’re on your own when you run into problems, plus having to do the due diligence of auditing the source code for malicious behavior ( I was responsible for defining the JS test setup for a project last year, and defending the trustworthiness of the open source tooling to the rest of the team was the main decision rather than the ergonomics of the test framework )