You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7778 Reporter: jfehrle Status: new Resolution: open Priority: normal Severity: feature Version: 4.06.0 Category: language features Monitored by:@diml@yallop@yakobowski
Bug description
One of the purposes of .mli files is to define a public interface for a module that hides implementation details; the .mli hides functions and data that should not and cannot be accessed from other modules. However, for testing, frequently it would be very useful to be able to write tests against the hidden items, such as with OUnit.
Is there a reasonable, relatively easy way OCaml could make the hidden functions accessible in test code, such as through a command line flag when compiling the tests?
A few other approaches I considered and rejected:
Put unit tests in the same file as the code under test. This makes it harder to distinguish changes to tests vs changes to code--both when looking at diffs of individual files and the list of files changed by a git commit. Also seems like you'd need to add one or more functions to the .mli file to make the test functions accessible. And it would be odd to include the tests in the object code, especially if the code will be widely distributed.
Remove the .mli files: I wasn't sure whether this is valid. Not very convenient, especially if you're running tests in a source tree you're in the midst of modifying. May also make for a slower edit-build-test loop.
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.
I agree with the intent, but the feature feels a bit ad-hoc to me. Additionally, this looks like something that could be easily implemented as a ppx. So if you'd like to push in that direction, you could start by implementing a ppx rewriter that does this and experiment with it. Once the feature has matured outside of the compiler and it is clear that it is a good feature, then you could propose it again.
Original bug ID: 7778
Reporter: jfehrle
Status: new
Resolution: open
Priority: normal
Severity: feature
Version: 4.06.0
Category: language features
Monitored by: @diml @yallop @yakobowski
Bug description
One of the purposes of .mli files is to define a public interface for a module that hides implementation details; the .mli hides functions and data that should not and cannot be accessed from other modules. However, for testing, frequently it would be very useful to be able to write tests against the hidden items, such as with OUnit.
Is there a reasonable, relatively easy way OCaml could make the hidden functions accessible in test code, such as through a command line flag when compiling the tests?
A few other approaches I considered and rejected:
Put unit tests in the same file as the code under test. This makes it harder to distinguish changes to tests vs changes to code--both when looking at diffs of individual files and the list of files changed by a git commit. Also seems like you'd need to add one or more functions to the .mli file to make the test functions accessible. And it would be odd to include the tests in the object code, especially if the code will be widely distributed.
Remove the .mli files: I wasn't sure whether this is valid. Not very convenient, especially if you're running tests in a source tree you're in the midst of modifying. May also make for a slower edit-build-test loop.
Generate new .mli files that include all functions defined in the .ml file: Generating the .mli files is non-trivial, plus has the same inconveniences as Parse -.x**2. (unary -.) as -.(x**2.). Fix PR#3414 #2.
Caveat: I've not used OUnit yet--I may have missed something in it that addresses my concerns.
The text was updated successfully, but these errors were encountered: