Open JJ opened 4 years ago
Hi,
Test::META
mostly depends on the features of META6
to determine the specification so from an arbitrary file or a parsed JSON data structure would be entirely doable (just a matter of splitting out some multi or so,) but supporting objects of some other class that might describe a META6.json
would be somewhat trickier (at a first guess I'd go with splitting off another module to define the expected interface, the traits that help define the specification and so forth.)
On the other hand it is entirely possible to test an arbitrary file by setting $*META-FILE
before calling meta-ok
(it's just not documented.)
FWIW, the actual test functionality in Test::META
is available in our
scoped subroutines that take a META6
object and return a Bool
if someone really wanted to do something else (I didn't document this because it was just for the convenience of the modules own tests originally.)
Hi,
Test::META
mostly depends on the features ofMETA6
to determine the specification so from an arbitrary file or a parsed JSON data structure would be entirely doable (just a matter of splitting out some multi or so,) but supporting objects of some other class that might describe aMETA6.json
would be somewhat trickier (at a first guess I'd go with splitting off another module to define the expected interface, the traits that help define the specification and so forth.)
OK, I see what you mean. There're META6 properties that can be tested by just looking at it, there are others that need to check the whole distribution. I was thinking mainly about the first group; but of course you have a more global vision. In that case, could we maybe spin meta-file-ok from meta-ok?
On the other hand it is entirely possible to test an arbitrary file by setting
$*META-FILE
before callingmeta-ok
(it's just not documented.)FWIW, the actual test functionality in
Test::META
is available inour
scoped subroutines that take aMETA6
object and return aBool
if someone really wanted to do something else (I didn't document this because it was just for the convenience of the modules own tests originally.)
Yep, I can see what you mean. That might be another nice option. Thanks!
In some use cases (like for instance when testing for the ecosystem) you already have a META6. object handy; right now get-meta just reads the current META6.json, it would be nice if we could provide an alternative object, or even file (well, it would be quite enough with the object, since you can get that from the file, I guess)