| > Did you try to use OCaml and run into a bunch of difficult problems? Yeah, I am a long date contributor and user of ocaml for little projects (mostly compilers and AIs). But not professionally. > It's been years since I used OCaml and I don't know anything about OPAM so I'm also interested in the answers. Opam is Bundler done right. It manages ocaml toolchains and packages dependencies. It's easy to pin a specific version or publish your own. A setup oasis + ocamlbuild + $editor could go quite far. After that, it will depend of how you works and what you are developing. > Like, testing is basically just checking a bunch of if statements. You can use fancy frameworks that color your tests red and green, but other than that kind of thing, what's the actual problem? Why do you say testing in isolation is particularly challenging with OCaml? That is a very interesting question that deserve a blog post on its own. But I don't have the time nor the patience to do so, so let it be the HN comment. > Like, testing is basically just checking a bunch of if statements. Wrong ! There's multiple kind of "if statements to test"; -1- I want to test that `my_inner_fibo(0, 1) == 1`. This is unit test. Basically a transcript of the technical specifications into assertions. This is the easiest test, the most verbose, but it's also the kind that test the least. -2- I want to test that `UserModule.retrieve_orders(user, command)` makes the good calls. This is integration testing in white box, which test that the API contracts between you inner interfaces are respected (which is also part of the technical specifications). I don't find it very useful but it's better than nothing when you can't do more. -3- I want to test that, with a given state `user`, and `command`, when I call `UserModule.retrieve_orders(user, command)` I get exactly this object. This is integration testing in black box. This is useful to find errors in inner logic a group of modules (but you don't know immediately what gone wrong). As the call stack could be very large (and so the scope of what you are testing), you want to reduce the moving parts and replace some of the modules with trivial mocks. Integration testing in a black box test a lot of things and is very useful to find bugs. -4- I want to test that a call to `$./my-binary ctl command --flag=true` have a specific behavior. Could also be a network request to a server, a message to a deamon, a click on a GUI... Anything exterior to the program. Here we test the behavior. This is what the user will use, that's why it's functional testing. This could break often (in the case of a GUI) or not (in the case of a CLI binary). You should always do functional testing if you respect you users a little. All these kinds of testing have different requirements, and some need a perfectly controlled state to be created. The issue is not in the conditional testing, but in the setup this perfect controlled state, which sometimes need to make the code believe it use the good module, but you gave him a stubbed one which does trivial work, or signal you when something happens. I don't know any simple way to spy on functions without using the MirageOS design which heavily use Functor injunction. It's quite an academic way of doing it. |
As an example, I want to make sure that when I hit a REST API endpoint, I do all my logic and get a proper return value (black box testing), maybe that the state of some bit that I've already set up is correctly changed (say, the database, by then checking it as part of the test to ensure the thing I said should be written was written), but that I also send a server sent event (SSE) to connected clients indicating the change. I don't want to actually have to have opened up clients that conform to the SSE specification as part of my integ tests (because that's a pain), so instead, I'll just assert that the library call to send that event does indeed get called with the right thing. From there, I can test once, that the library call does indeed lead to an SSE being sent to the browser (and can even write a full environment integ test with Selenium or something), and from then on, my single system tests just assert that call is made when it's supposed to. I'm effectively integration testing without implementing/mocking a connected user to test SSEs.
Similar things can be useful when putting items onto external queues, making calls to foreign interfaces, etc. You should never make assertions about the path through your code a call takes in white box testing (because refactoring can change those, and you have increased your test burden for little reason), you should care about side effects you can't easily otherwise test.