@georgemillo I've started moving away from tests like that. I test the actual result. I.e if I pass in this input, I expect to get the following errors. I think you get a more reliable result that focuses more on what matters (when my object is valid vs invalid and why) than the exact code I used to get there. Less coupling on the exact implementation therefore less brittle tests etc.
Plus as soon as you get advanced edge cases that depend on injected objects (say current user) you either end up testing manually or having such a complex matcher that it slightly defeats the point of having such a clean implementation library like dry-validations ! (Just my personal opinion of course 😜)
@fran-worley yeah, my custom matchers work like you described (passing in input, seeing if its valid), rather than testing the actual code (not even sure how you'd do that, presumably there's some way to reflect on the Schema class to figure it out)
where I realise I've gone wrong through is testing things at such a low level, i.e. at the level of the schema itself rather than the place that uses it (e.g. a reform form)