Show HN: Distilled – An unopinionated, drop-dead simple JS testing framework

Hi, author here.

I wrote Distilled a little over 2 years ago because I was frustrated with the complexity and quality of existing JS testing frameworks. It's primarily targeted at people who want to keep their codebases simple and who want to have highly customized testing setups for each of their projects.

I've been using Distilled on all of my projects for 2 years now for both unit and integration testing. I'm obviously biased, but I think it's pretty good.

The testing API for Distilled is only 1 method, and the full API is only 3 methods. This makes it pretty simple to set up and use -- on most of my new projects I'm able to start writing unit tests less than a minute after running `npm init`. Usually I won't even set up a testing harness until after I'm done prototyping, I'll just run my tests in the same file as my implementation.

On the other hand, because the API is very composable, I've also been able to build a lot of weird, project-specific testing setups. For example, all of the documentation on the main site is generated from Distilled's own unit tests -- that way I always know it's correct. That would have been a pain to do with most testing libraries, but with Distilled I was able to just build a couple of quick wrappers and I was good to go.

Distilled also supports a couple of power-user features that I've found really useful:

- Tests can be infinitely chained or nested, which allows me to have children test which will get automatically skipped if their parents fail. This helps a lot with organization, and speeds up execution because when one test fails you don't have to wait for all of its dependent tests to also fail.

- Assertions are recursively resolved, which means you can have a function that returns a function that returns a Promise, and Distilled will just handle it. This is incredibly useful if you're trying to quickly build a high-level framework on top of Distilled, or change a built-in behavior.

- All tests are async, because the majority of Javscript code is async, and it doesn't make sense for a testing framework to resolve assertions synchronously by default. I've also put a lot of effort into making sure that test resolution follows native Promise resolution rules as closely as possible.

Let me know what you think!