Amazing to see Jane Street uses Emacs. And property-based testing too.

> you don’t just get a build failure telling you that you want 610 instead of a blank string

So I had to scratch my head a bit because I was thinking: "Wait, the whole point is that you don't know whether what you're testing is correct or not, so how can you rely on that as input to your tests!?".

But even though I didn't understand everything they do yet I do see at least a big case where it makes lots of sense. And it happens to be a case where a lot of people see the benefits of test: before refactoring.

> What does fibonacci(15) equal? If you already know, terrific—but what are you meant to do if you don’t?

Yeah a common one is reuse a function in the same language which you believe is correct (you probably haven't proven it to be correct). Another typical one is you reuse a similar function from another language (once again, it's probably not been proven it is correct). But if two implementation differ, you know you have an issue.

> let d = create_marketdata_processor () in > ( Do some preprocessing to define the symbol with id=1 as "APPL" )

Typo. It's AAPL, not APPL. It's correctly used as AAPL later on.

FWIW writing tests better become a joyful experience for we're going to need a lot* of these with all our AI generated code.

I really like this style of testing -- code that can be tested this way is also the most fun kind of code to work with and the most likely to behave predictably.

I love determinism and plain old data.

This is a cool idea. I wish something like this existed for C#.

mdx[1] is another variation on this, also in the Ocaml ecosystem. It’s Ocaml’s version of documentation tests as in Elixir and Rust.

But it’s not limited to that. You can write tests in markdown files independently from your documentation. Use “dune test” to run the tests and review failures with “git diff”. Accept the changes if they are correct (changed behavior) with “dune promote”. Very nice workflow.

[1] https://github.com/realworldocaml/mdx

Since when has writing tests not been a joyful experience?

I do see a lot of useless tests out in the wild. I can see writing those not bringing any joy. That is true of any useless activity. Is that what we're thinking of here?

In my experience the lack of joy or difficulty with tests is almost always that the test environment is usually different enough from the real environment that you end up needing to kind of stretch your code to fit into the test env instead of actually testing what you are interested in.

This doesn't apply to very simple functions but tests on simple functions are the least interesting/ valuable.