[Beta announcement] rescript-zora: Lightning fast unit tests

[dusty-phillips]

Hi everyone! I sat down yesterday to write some Rescript bindings to the zora test framework. I chose Zora because it has good SEO for “fastest Javascript test runner”. Rescript taught me that speed is far more important to flow than fancy tooling, so I wanted to get the same experience in my unit testing.

It wasn’t hard to model, but I thought it would be worth sharing my work. I honestly think Zora could become the go-to testing library for the Rescript community.

dusty-phillips/rescript-zora

Suggestions are welcome, pull requests more so!

[chenglou]

Whoops, we were actually gonna release some testing utils as a surprise… this is awkward…

Though yes, speed is definitely a lesson we wanted to teach. Regarding testing, maybe there are a few more. Stay tuned… in the meantime, congrats on releasing!

[hoichi]

One potential upside of binding to a JS framework is that there will possibly be more integrations: with editors, with runners, with coverage tools, etc. Then again, maybe all those are non-essential: when your tests are fast enough you don’t have to run a subset of them, having to debug a test means a design problem, etc.

Also, it seems we won’t have a perfect IDE (or, say, Wallaby.js) integration until we have source maps, and I guess it’s still not a priority for the team (to clarify: I’m not insisting that it should be).

[jorge]

wallaby is awesome. but won’t renew my license until ReScript is compatible

[hoichi]

I was meaning to try whether it’s feasible to run it against the compiled tests, but I don’t have enough tests so far

[chenglou]

Well our community definitely does bind to JS testing frameworks just fine, barring those extreme vertical integrations you’ve mentioned.

But in the case of testing: yes, performance over fancy features. See here and here for example.

Busy this week but I’ll see if I can release the util soon.

[kanishka]

This was what I was expecting. Most new languages define a test framework pretty early on, and start dogfooding it.

[flo-pereira]

can we imagine writing test directly near non-test code the way it done in Rust ?

let add(a, b) => a + b

@cfg(test) // any special test decorator
module Tests = {
    let test_add = () => {
    expect(add(1, 2)).toBe(3);
}

[yawaramin]

This exists in the native OCaml world, btw, so it’s not a strange idea at all: https://github.com/janestreet/ppx_inline_test

Personally, I would prefer to keep tests in a separate directory, because imho:

1. Tests should treat the code under test as a black box and not have special access to it.
2. We shouldn’t be forced to compile live and test code at the same time; putting tests inline would mean recompiling all test code even if you want to just check some live code e.g. with a hot code reload in the browser.
3. Keeping tests separate removes any headaches related to stripping out test code from deployed production code output, especially relevant for JS.

[flo-pereira]

1 - … don’t see any problem with that

2- Taking Rust for exemple that is what « cfg(test) » decorator is used for, a conditional compilation, mean that you only compile this part of code for a given configuration

3- You can use the same decorator to exclude test code from production build.

I like the way Rust let write unit test directly near the code that they’re testing because it makes it easier and improve coverage !

That’s just an idea… As all files in Rescript are a module, it may be a possible to write the both way

[spyder]

I’ve been using mocha, which I thought was pretty fast, but it looks like zora is really fast!

I wonder how hard it would be to migrate thanks for these bindings!

[kay-tee]

@chenglou

Whoops, we were actually gonna release some testing utils as a surprise… this is awkward…

Any update on these testing utils?

[kay-tee]

Just a note, if you use the 1.0 version of pta (the zora-node test runner) instead of the version listed in @dusty-phillips repository’s package.json (0.2.3) it will only recognize the standalone tests.

For example, the 1.0 version of pta will not recognize the test created by this example given in rescript-zora repository:

// simple.test.res
open Zora

let default: zoraTestBlock = t => {
  t->block("should greet", t => {
    t->ok(true, "hello world")
  })

  t->block("should answer question", t => {
    let answer = 42
    t->equal(answer, 42, "should be 42")
  })
}

So if you upgrade pta to the 1.0 version the standalone tests work, but only the standalone tests–opposite of the 0.2.3 version.

[dusty-phillips]

I’ll take a look at the pta 1.0 changelog and see if I can find a fix and/or update the docs.

[dusty-phillips]

Looks like PTA has just removed the requirement/support for modules. I like it better this way; I don’t have to make a decision as to whether to write a stand-alone file or not.

Have updated the dependency along with docs and examples in the 2.0.0 release here: @dusty-phillips/rescript-zora - npm

[mudrz]

hi, @chenglou, should we wait for new test utilities coming from the rescript team?

[kanishka]

I tend to value features over speed for a testing library. Most times, I want a small delta of tests to be run, based on what tests have been impacted by a code change or a specific module that I’m working on. I also like being able to filter tests online and seeing which tests match my regex filter.

I can relate to wanting speed for CI builds which might run the full suite.

[mouton]

Dusty if you ever wanted to write up what you did to get these tests running with files that include external packages etc I’d love to see it. In between type=“module”, rescript compiling into node_modules, and large existing codebase I had to use parcelJs and wrote my own external interface for competitor AvaJs to get some rescript tests running (and still have to refactor around window access etc)

Thanks
Alex

[dusty-phillips]

I haven’t had a lot of luck with it actually. There are a couple articles on my blog, but at least one of them breaks node. I think setting rescript up to compile to the .mjs suffix with es6 syntax was my least unsuccessful solution, but it still got confused when trying to build a rescript project that compiles to commonjs syntax (bs-express).

[peterh]

Just wanted to say thank you for sharing your work on those bindings. This is the first time I am thoroughly testing my project with a test framework and zora is pretty fast and easy to use, especially with the pta test runner that listens to changes on all .test files. Fits all my testing needs for now!