3 ms·

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

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. 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. 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 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 )

eyelidlessness 5y ago
I’m quite surprised by this response. I find the Folio pitch very compelling, I’m a TypeScript fanatic, and the TS accommodations are pretty low down the list for me in this case. For me the isolation story is by far the most interesting. Of course you can wrap an existing test framework to provide different kinds of isolation, to some extent. There are some things you can’t do with most if not all of the BDD-style JS test frameworks I can recall, for instance any kind of `aroundEach` where a test’s setup, execution and teardown can run in a shared call stack. This is useful (for instance) in situations where you might use CLS to wrap a test in a database transaction. At least walking up to this, that appears to be solved by their interface. Another thing it solves is providing matrix testing primitives where you can branch at the framework level depending on arbitrary environment differences. This is a godsend for library authors, and also for anyone integrating with a variety of external dependencies. Again, of course that could be solved by wrapping some more naive framework. But having the primitives first class and built in means: - You’re not reinventing the wheel. - There’s an idiomatic way to do it. That’s huge! This is stuff I’ve one-offed a zillion times because it never felt quite right. Now it’s a potentially shared problem, and people can coalesce around the solution.

eyelidlessness 5y ago

I’m quite surprised by this response. I find the Folio pitch very compelling, I’m a TypeScript fanatic, and the TS accommodations are pretty low down the list for me in this case. For me the isolation story is by far the most interesting. Of course you can wrap an existing test framework to provide different kinds of isolation, to some extent. There are some things you can’t do with most if not all of the BDD-style JS test frameworks I can recall, for instance any kind of `aroundEach` where a test’s setup, execution and teardown can run in a shared call stack. This is useful (for instance) in situations where you might use CLS to wrap a test in a database transaction. At least walking up to this, that appears to be solved by their interface. Another thing it solves is providing matrix testing primitives where you can branch at the framework level depending on arbitrary environment differences. This is a godsend for library authors, and also for anyone integrating with a variety of external dependencies. Again, of course that could be solved by wrapping some more naive framework. But having the primitives first class and built in means: - You’re not reinventing the wheel. - There’s an idiomatic way to do it. That’s huge! This is stuff I’ve one-offed a zillion times because it never felt quite right. Now it’s a potentially shared problem, and people can coalesce around the solution.