Failures and Verbosity
Andy Armstrong
andy at hexten.net
Wed Mar 4 19:01:50 GMT 2009
On 2 Mar 2009, at 17:14, David E. Wheeler wrote:
>> I see:
>>
>> * verbosity
>> 1 verbose Print individual test results to STDOUT.
>> 0 normal
>> -1 quiet Suppress some test output (mostly failures
>> while tests are running).
>> -2 really quiet Suppress everything but the tests summary.
>> -3 silent Suppress everything.
>> * failures
>> * comments
>> * show_count
>> * errors
>> * directives
>>
>> Am I missing any?
>
> 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
* leave the current interface intact and fix its inconsistencies
* clarify the code
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.
--
Andy Armstrong, Hexten
More information about the tapx-dev
mailing list