I'm contemplating the general problem of how best to classify and organize tests.
As a specific example, you might classify and organize your tests like this:
xt/author/pod-coverage.t
xt/author/code-coverage.t
xt/author/perl-critic.t
xt/stress/one-minute-test-run-under-memory-pressure.t
xt/stress/one-hour-thread-safety-test.t
xt/stress/twenty-four-hour-memory-leak-test.t
xt/doco/test-user-doco-1.t
xt/rtbug/rt123.t
xt/rtbug/rt456.t
# ...
An obvious limitation of such a scheme is that a test cannot simultaneously be in two different categories. For example, where should I place an rtbug test that is also a stress test? And a "stress" test may or may not be "long running" - what if I want to run all stress tests, but not the "long running" ones? Arguably, the short running stress tests should be in t/ and not xt/, so that they are run by "make test". Property-like metadata solves this problem, akin to adding "tags" to your photo collection. Tools like prove could be enhanced to allow you to specify boolean combinations of test metadata that you want to run.
Maybe what I'm proposing is YAGNI. It seems I'll need to come up with some specific, compelling use cases before I could hope to gain any support for this idea.
Update: Note that the xt/ directory layout recommended by Module::Install::ExtraTests is:
xt/author - run when the tests are being run in an author's working c
+opy
xt/smoke - run when the dist is being smoked (AUTOMATED_TESTING=1)
xt/release - run during "make disttest"
| 