Any update on these testing utils? 
7 Likes
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.
2 Likes
I’ll take a look at the pta 1.0 changelog and see if I can find a fix and/or update the docs.
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
2 Likes
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.
1 Like
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
1 Like
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).
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!
I have been thinking about this more and I would sacrifice features for implementation simplicity. In the case of jest, it seems like it has to reinvent parts of webpack, under the assumption that your testing system should help you with mocking and stubbing.
With ReScript and some form of dependency injection, I think developers wouldn’t need to use mocking. At that point, recreating webpack mechanisms no longer justified. You could implement your testing system as something that hooks into the final phases of webpack.
Some people have been pursuing this with vitejs: https://github.com/zigomir/vite-test. I hope more projects like this emerge. Then, you would have one centralized config for your dev server and test system.
1 Like
I feel the same way. I’ve wasted so much time trying to get finicky unit tests working. When I moved to Vite I put easily a dozen hours into trying to get jest working again for the few unit tests I have. I decided to punt on it and try to cover the majority of those tests with my integration tests instead.
1 Like
@dusty-phillips Just want to thank you for your bindings 
Since i’m using Hexagonal Architecture and DDD principles, i don’t need mocking (i just create InMemory implementations of my adapters), and Zora + ReScript is the best combo ever for testing.
I never had such fast tool for developing in TDD.
Best regards to you 
PS: I’m working on RxJs, Redux Toolkit & Pact bindings also, nice to have your repo as examples. It tends to be pretty straightforward to do bindings in ReScript, thx to their awesome API.
1 Like
I’ve gotten Jest to work but it is a bit slow. Two features I like with it though. I can see the tests in the VS Code test explorer and run specific tests on demand. I can also trigger a debug of any test and walk through the code. Can either of these be done with Zora?
It can be done, as a VsCode extension, which support TAP format.
I couldn’t find an extension. I searched for Tap and most recent was 2018.
I swapped from jest to zora in my port of reason-nodejs to rescript, I’m really happy with it!
https://github.com/TheSpyder/rescript-nodejs/tree/main/test/atomic
There’s a few weird parts of the bindings that I may log a ticket about at some point, but generally it was pretty seamless once I understood how to write in zora test style.
1 Like
@flo-pereira using inline tests in native OCaml, I find this feature very interesting and would love to see it in rescript too, I created a new post about it, don’t hesitate to chime in!
3 Likes
Try @swc/jest – SWC - a drop-in replacement for jest. I got 2x faster tests just by adding it to my config.
Over a year later, did this go anywhere or should I keep cranking on my vitest bindings?
2 Likes
I’ve been meaning to update this package to support async/await and Rescript 10.1 and finally got around to it today after a couple recent messages from folks agitating for it.
See GitHub - dusty-phillips/rescript-zora: Lightning-fast testing for a lightning-fast compiler
To be honest, I had kind of lost interest in Rescript because maintaining the promise-based tests in this package and rescript-dexie was tedious. The new async/await syntax is exactly what I wanted. Thanks to everyone who made it happen! <3 I would love to update the rescript-dexie bindings as well and maybe even republish some of my articles, but I am super busy with (non-code) things lately and not sure I’ll have the time.
9 Likes