On Fri, 01 Nov 2013 13:45:08 +1000
Nick Coghlan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/01/2013 03:53 AM, Tim Flink wrote:
> > On Thu, 31 Oct 2013 07:17:03 -0400 (EDT) Josef Skladanka
> > wrote:
> >> I do not really feel that this is a good match for our needs (at
>
On Thu, 31 Oct 2013 07:17:03 -0400 (EDT)
Josef Skladanka wrote:
Bah, just realized this only went to Josef the first time I sent it. He
gets two copies!
> Tim (and of course the rest of the gang ;)),
>
> During our chat with Tim, we agreed that we'd really like to use some
> standardized 'outpu
On 10/31/2013 02:27 PM, Josef Skladanka wrote:
Lucas,
do you use any library for producing TAP format?
No, at least not in the sense of an external project. Producing TAP in
the client is an autotest specific implementation. It is the TAPReport()
object defined in:
https://github.com/autot
On 10/31/2013 01:23 PM, Kamil Paral wrote:
= TAP =
TAP is not unittest-specific, and is human-readable plaintext format.
It also has just PASS/FAIL logic, but there is a possibility to add YAML
'metadata' to any result (since TAP v. 13).
The real issue with TAP is Python support.
There is a TA
On 10/31/2013 01:23 PM, Kamil Paral wrote:
= TAP =
TAP is not unittest-specific, and is human-readable plaintext format.
It also has just PASS/FAIL logic, but there is a possibility to add YAML
'metadata' to any result (since TAP v. 13).
The real issue with TAP is Python support.
There is a TA
> = TAP =
>
> TAP is not unittest-specific, and is human-readable plaintext format.
>
> It also has just PASS/FAIL logic, but there is a possibility to add YAML
> 'metadata' to any result (since TAP v. 13).
>
> The real issue with TAP is Python support.
> There is a TAP-consumer library created
