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