On 7/5/25 14:36, Soham wrote:
Thanks for the replies everyone!
On 7/3/25 21:40, Jacob Bachmeyer wrote:
[...]
TAP *should* *not* have semantics for that. TAP scripts are supposed
to be runnable directly or through trivial harnesses like piping the
output through `grep 'not ok'`. If the meani
Thanks for the replies everyone!
On 7/3/25 21:40, Jacob Bachmeyer wrote:
On 7/3/25 18:11, Russ Allbery wrote:
Karl Berry writes:
[...]
This confusion comes from not clearly thinking through what the test
*is*. A proper test verifies conformance to a specification. The
example from the D
Jacob Bachmeyer writes:
> In this case, the specification is "The syscall shall return an error if
> given an invalid argument." and the test provides an invalid argument and
> expects an error return code. The test *passes* ("ok" in TAP) *if* *and*
> *only* *if* the syscall reports failure when
On 7/3/25 18:11, Russ Allbery wrote:
Karl Berry writes:
[...]
I'm far from familiar with the ins and outs of TAP and its conventional
usage, but it seems like a matter of semantics to me. It can be
convenient and intuitive to write a test such that it "fails", like
Sohan's example of a syscall
Karl Berry writes:
> See https://testanything.org/tap-specification.html under "TODO tests".
> Thanks Russ. But what Soham is describing is not at all a "TODO" item as
> described there.
> I'm far from familiar with the ins and outs of TAP and its conventional
> usage, but it seems like a m
See https://testanything.org/tap-specification.html under "TODO tests".
Thanks Russ. But what Soham is describing is not at all a "TODO" item as
described there.
I'm far from familiar with the ins and outs of TAP and its conventional
usage, but it seems like a matter of semantics to me. It ca
Soham writes:
> Well, I forgot to clarify in the original email, but my particular
> target use-case is is "unit tests" written in code, say for a particular
> function or class. In that case it gets cumbersome to have one binary
> per test (atleast IMO). My idea is to add support for a TAP outpu
On 7/2/25 13:00, Soham wrote:
[...]
Well, I forgot to clarify in the original email, but my particular target
use-case is is "unit tests" written in code, say for a particular
function or
class. In that case it gets cumbersome to have one binary per test
(atleast IMO).
My idea is to add suppo
On 7/1/25 15:37, Andrew W. Nosenko wrote:
Autoconf’s Autotest has notion of expected-to-fail (aka XFAIL) tests and it
served my needs very well about past 18-20 years.
Sent from mobile
Yes, that is a similar feature. As I just wrote to Bob, it doesn't
really work
for "unit tests" for functio
Hello, Thanks for the input!
On 7/1/25 15:24, Bob Friesenhahn wrote:
GraphicsMagick uses a custom TAP-test script (patterned on the example
one from Automake) where there is support for deciding if the test is
expected to fail based on a list of features. For example, the support
for a file f
Autoconf’s Autotest has notion of expected-to-fail (aka XFAIL) tests and it
served my needs very well about past 18-20 years.
Sent from mobile
On Tue, 1 Jul 2025 at 22:24, Bob Friesenhahn <
graphicsmagick.proj...@gmail.com> wrote:
> GraphicsMagick uses a custom TAP-test script (patterned on the
GraphicsMagick uses a custom TAP-test script (patterned on the example
one from Automake) where there is support for deciding if the test is
expected to fail based on a list of features. For example, the support
for a file format may depend on an optional library and that library is
a "feature
On 6/30/25 16:41, Soham wrote:
Hello,
I recently was using the tap driver provided by automake, and noticed
that there currently is no way to declare a test as xfail or xpass
apart from marking it as "todo". The test ouput however does produce
rows for XPASS and XFAIL, and the existing TRS fo
13 matches
Mail list logo
