# from brian d foy
# on Friday 12 October 2007 06:33:
>The profile at the end of that looks interesting, and I immediately
>thought about a way in your format to declare prereqs per test (rather
>than just per directory).
That is certainly possible, but IMO not as handy for use with existing
tools (though it is workable as long as the special tests are "out of
the way".)
aside(
>You wouldn't have to say anything about
> tests that don't need anything special, just tests that are special.
Why would non-special tests be in xt/? If you're thinking of special
tests which live in t/, they will need to require the meta-data module
and use it to determine whether to skip_all. That's not the scheme I'm
building, but the usefulness of the meta-data is not restricted to this
scheme.
)
As for per-test, I think it is important to approach the formal system
(an API and/or protocol) from the definition of "resource profiles".
This reduces duplicated information vs. declaring requirements
per-test. The worst case is one test per profile, but note the way
that tests are using multiple profiles in the example (e.g.
gui.network.) Perhaps I'm mis-reading your statement -- the important
bit is that extra_testing.yml does not contain test names.
The manifest.yml data-structure can be transformed to use tests or
profiles as keys. You could certainly define the profiles and then
write a per-profile manifest (ala the 'other/' directory.) The
directory scheme is intended to allow this manifest to be derived from
the directory names (and to provide convenient ad-hoc organization for
the case where the meta-data system is not supported by
$existing_tool.)
Since we've already heard multiple opinions about the directory name, I
think we'll need to settle on something for explicitly declaring that
in META.yml, e.g. "extra_tests => 'xt'".
Similarly, it is probably necessary to declare the "schema" in some way
if the directory layout is going to differ. You can then have an API
which returns a "$profile => [EMAIL PROTECTED]" manifest and not need to force
filename assumptions into the test tools.
Of course, those two items mean pain for the developer because META.yml
would have to be generated *before* the extra tests could be run.
Perhaps we need a dev_meta.yml? (which would be spliced into META.yml
ala what M::B does with meta_add.)
--Eric
--
But as soon as you hear the Doppler shift dropping in pitch, you know
that they're probably going to miss your house, because if they were on
a collision course with your house, the pitch would stay the same until
impact. As I said, that one's subtle.
--Larry Wall
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
