Failures and Verbosity
David E. Wheeler
david at kineticode.com
Wed Mar 4 19:29:13 GMT 2009
On Mar 4, 2009, at 11:01 AM, Andy Armstrong wrote:
>> So where do we want to go with this? Maybe a string argument? Or an
>> array of strings? That way, we can specify levels pretty granularly.
>> The various things to display include:
>>
>> * failures
>> * comments
>> * counts
>> * errors
>> * directives
>> * summary
>>
>> Do we need any more? You can specify them singly or as an array:
>>
>> show => 'failures',
>>
>> show => [qw(failures comments errors)],
>>
>> Or you can use one of a few aliases that correspond to the old
>> numeric
>> levels, but now just act as aliases for the appropriate arrays of
>> arguments:
>>
>> * verbose - [qw(failures comments counts errors directives)],
>> * normal - [qw(counts summary)],
>> * quiet - [qw(counts summary)],
>> * quiet - [qw(summary)],
>> * silent - [],
>>
>> I'm not exactly sure what should be in each of these, but we should
>> add keys for anything that's missing to make the appropriate arrays
>> (for example, I added "summary").
>
>
> I prefer the second option. Done right it should
I thought I only had one proposal. You can send arguments for
individual things to show in the output (failures, comments, counts,
etc.), or you can use aliases that stand for some subset of those
things. Most would prefer to use the aliases, of course, but I
suggested the fully granular options because that's what we have now.
> * leave the current interface intact and fix its inconsistencies
> * clarify the code
Agreed.
> We still have fairly ugly bits of code here and there that decide what
> to display based on the verbosity level. Having well defined channels
> that can be checked simply should improve that code.
Yep.
Best,
David
More information about the tapx-dev
mailing list