I have a couple of ongoing side-projects that I use to practice my OCaml every now and then, whenever I have some free time. The other day, I wanted to use fixtures for a test and it took me a while to get it to work properly with Dune, so I thought it was worth a write-up!
I’m sharing it here because I would be especially interested in having some feedback from other OCaml developers, seasoned or not. <3
let text = In_channel.(with_open_test "fixtures/data.txt" input_all) in
I think you mean with_open_bin?
Ah, good catch. I have been using with_open_text since they are JSON files in my current project, but I guess I should be using with_open_bin if I’m working with non-text files?
In general you never want to use open_text (and {input,output}_line) it will only get you into trouble. They are useless and confusing for text input, and harmful for text output (they transform your data behind your back on some platforms).
@Richard-Degenne Thanks for this! I’m a hobbyist programmer and struggle with Dune in exactly the way that you describe. I love it, but also find that it has a really steep learning curve and often struggle to figure out how to do what I want to do. Despite the docs been good in so many ways.
Short posts like this are great! Thanks for taking the time to write it up!
I would also like to point out that if there’s a specific issue with the Dune documentation, where you think it could be cleaner and e.g. explicitly state things instead of sort-of implying them (the linked documentation does state that the test stanza supports <optional fields>), you are more than welcome to open a PR to improve the documentation. Because for every confusing aspect you have figured out, there’s probably a lot of other people who wonder the same question and can’t figure it out.
Adding a paragraph saying something akin to “tests can depend on extra files but these need to be declared as dependencies like so […]” could be a valuable improvement to others reading the documentation and trying to figure things out.
Reading the blog post I want to point out that unless you rebind == then the test will always fail:
assert (text == "Hello, world!")
The default == operator compares physical equality thus "Hello, world!" == "Hello, world!" is false. Only let s = "Hello, world!" in s == s would evaluate to true.
(Of course I realize that the actual code of the test is only tangentially related to the point you’re making in the post)
Good catch. It’s pure muscle memory from other languages where == is logical equality. 