Anonymous | Login | Signup for a new account | 2018-04-27 10:18 CEST | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
0007778 | OCaml | language features | public | 2018-04-16 00:36 | 2018-04-16 13:38 | ||||||
Reporter | jfehrle | ||||||||||
Assigned To | |||||||||||
Priority | normal | Severity | feature | Reproducibility | have not tried | ||||||
Status | new | Resolution | open | ||||||||
Platform | OS | OS Version | |||||||||
Product Version | 4.06.0 | ||||||||||
Target Version | Fixed in Version | ||||||||||
Summary | 0007778: Provide a way for unit tests to access functions and data hidden by the .mli file | ||||||||||
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: 1. 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. 2. 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. 3. 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 #2. Caveat: I've not used OUnit yet--I may have missed something in it that addresses my concerns. | ||||||||||
Tags | No tags attached. | ||||||||||
Attached Files | |||||||||||
![]() |
|||
Date Modified | Username | Field | Change |
2018-04-16 00:36 | jfehrle | New Issue |
Copyright © 2000 - 2011 MantisBT Group |