Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’m building yet another JS test framework. I care if it succeeds in the sense that I want to use it for my own purposes, but I couldn’t care less if it gets more adoption than that.

Why I’m building it/what it is:

- Disclaimer: I don’t intend to shit on any work by comparison, everything else is also a monumental effort and in most cases a labor of love as well

- Problem: there are several “blazing fast” alternatives which either are not as fast as they think, or are feature limited and hard to extend

  - Not as fast as they think = highly optimized but their metrics omit their biggest overhead (eg spinning up new threads)

  - Feature limited = poor support for ESM, build tooling at runtime, caching and mocking don’t work as expected
- Concurrent, isolated testing by default, with a lot of tuning to provide threaded parallelism without noticeable overhead where possible (startup will always have a noticeable cost, this is aimed at subsequent runs in watch mode)

- ESM first, natively, correctly according to standards

- TypeScript without additional build config or FS output

- TS support is built on ESBuild, but I’m taking care to work around some of its limitations like lack of support for the new JSX transform

- ESM imports can be mocked trivially without memory leaks

- Ergonomic improvements to common setup/teardown APIs: beforeAll/beforeEach can return isolated values for tests

- APIs for aroundAll/aroundEach which allow tests to be executed in the same stack as they’re declared, which in turn means you can use things like async hooks and other stack local references (motivating use case: rolling back transactions to a clean current db state without re-running migrations)

I’m probably forgetting other nice things going into this. And it’s just a yak shave project because I want this to test more concrete things I want to build



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: