Description
(Filing this issue in response to discussion on #214.)
I frequently find myself brushing up against limitations in the file formats that trycmd
currently supports. (I am one of the top historical contributors to Mercurial, whose expressive .t
test format / harness was the inspiration for cram. cram exposes a subset of what Mercurial's .t
format supports (for better or for worse). And trycmd
a subset of cram's. So from my perspective the feature set of trycmd
is somewhat limited.)
It seems I'm not alone. Scanning the issue tracker for this project reveals a handful of other users wanting extensions to the file format.
I'd like to propose a new feature (which I initially proposed in #214): support for custom file loaders. The way it works today is trycmd
is the lone arbiter deciding how tests are defined and loaded from files. My idea is to provide an API that allows customers to bring their own file formats / loaders. This requires opening up the TryCmd
struct to the public API (#217).
If customers are able to define their own file formats, they are able to experiment with extensions to the current file format or completely different file formats entirely. All while reusing the internals of trycmd
to run tests. This could lead to a world where people proposing new file format features are encouraged to experiment on their own projects first before coming back to this project with a clear demonstration of value to justify inclusion in the official file format.
As a tangible example of this, using trycmd
with my patches from #214, I built a custom test runner that supports running .trycmd
tests from a filesystem sandbox of the crate root - something not possible with .trycmd
tests using the public API available today. This only scratches the potential of what's possible.