Michael G Schwern <[EMAIL PROTECTED]> writes: > Ovid wrote: >> --- Steffen Schwigon <[EMAIL PROTECTED]> wrote: >>> And we are talking about the diagnostics part, which is primarily for >>> the user, so the rules are reversed there. >> There are two goals we want: >> 1. Make it as human-readable as possible. >> 2. Maximize flexibility. >> As for human-readable, consider these: >> results: >> tap-have: 4 >> tap-want: 5 > > <mccoy>It's worse than that, Jim.</mccoy> > > tap-results: > tap-have: 4 > tap-want: 5 > > tap tap tap tap tap.
Then maybe I haven't understood what the standardization of diagnostics is about. I thought it is primarily meant for the *user* of TAP to transport its own diagnostics of its own test runs and test results? I for instance would use it to transport benchmark results inside tests. I hadn't expected much of *TAP* specific stuff there. So the above horror scenario with "tap tap tap everywher" is not really happening. Or are the YAMLis keys of diagnostics expected to transport all what current typical Test::* modules provide? This would include, for instance, all the diagnostics that may result of is ok is_deeply like isa_ok file_exists file_empty file_size file_max_size (min) file_readable (executable) file_mode file_is_symlink owner test_verbose lives_ok dies_ok critic_ok all_critic_ok all_code_files and many more. This is probably not what standardization of keys withing diagnostics is about. Or is it? Can you give me examples what keys you try to standardize as part of TAP inside diagnostics? I interpret the examples of TAP13 with "data", "expect", "got" in http://podwiki.hexten.net/podwiki.pl?page=TAP13 as "user keys", i.e. *not* standardized as TAP. Steffen -- Steffen Schwigon <[EMAIL PROTECTED]> Dresden Perl Mongers <http://dresden-pm.org/> Deutscher Perl-Workshop <http://www.perl-workshop.de/>
