trycmd icon indicating copy to clipboard operation
trycmd copied to clipboard

Make TryCmd constructable by end-users

Open indygreg opened this issue 2 years ago • 3 comments

(Filing this issue in response to discussion on #214.)

As I made the case for in #214, there is value in leveraging trycmd's internal data structures (namely TryCmd and everything its fields reference) to build your own process based snapshot testing library or to bend trycmd to your will. If you could construct TryCmd instances manually (bypassing the file loaders that are forced onto us today), this would create opportunities for customers to experiment with different file formats and different ways of constructing test cases. It would enable customers to leverage the test running functionality in the trycmd crate without having to reinvent that wheel. i.e. I think it would increase the overall value of the trycmd crate.

The code changes for this are minimal (https://github.com/assert-rs/trycmd/pull/214/commits/77e05d79d3afcafc9dc603542ceb050156a87760). I suspect the real debate is what the crate API surface area should be. Obviously sprinkling pub everywhere has semver and API support implications.

indygreg avatar Jun 28 '23 02:06 indygreg

Before getting into how to solve this, can we focus on the use cases? We offer snapbox as a lower level snapshotting library. What is it you are trying to accomplish that the current structure of trycmd and snapbox are getting in your way?

epage avatar Jun 28 '23 13:06 epage

I don't want to have to build my own runner (with steps), diffing functionality, etc.

I agree that snapbox is a useful foundational crate to have. But there's just enough functionality missing that I wanted to reach for trycmd's abstractions instead of reinventing the wheel.

indygreg avatar Jun 29 '23 01:06 indygreg

@indygreg maybe tryfn can suit your needs ?

stormshield-gt avatar Jun 20 '24 18:06 stormshield-gt