| > I'm always very amused when people say OCaml can't work at "enterprise scale" Yeah, you will notice that quotes that show you shouldn't take it too literally. ;) (also I have no doubt that Ocaml can work in a business. I just saw no one speak about it appart Jane Street, so I am curious) What I was meaning that "a team with a hierarchical organization, not-ony-geniuses, and more than 4 people". Few of the serious Ocaml projects (if any) fall in this category, which is common for all businesses. About the testing tooling, I am well aware of the state of these technologies. I even contributed to some of them. Sorry but it's light. It doesn't cover all the spectrum of what you'll want to test in a product. Let's take your (excellent) libs and see: - OUnit: unit tests - QCheck: unit tests - iTeML: unit tests Where is integration and functional testing ? Unit Testing only test a very strict subset of the "does this work as intended" question. I recommend you to see how some projects do their testing. For example any classic Rails project. You could be surprised. Some open questions I struggle myself to answer correctly: - Mocking modules without having a build mess with oasis - Managing the model in a sane way - Integration testing is an horror And many more that I can't recall now. |
> Mocking modules without having a build mess with oasis
OCaml has parametrized modules (aka "functors"), which provide a very clean solution, compared to mocking whole modules anyway.
As a side note, I usually see mocking being used to test badly structured code. Refactoring that is usually a benefit for testing as well as a benefit for the code itself.