On 20 May 2016 at 16:49, Mathieu Lirzin wrote:
> Reuben Thomas writes:
>
> > On 19 May 2016 at 00:04, Mathieu Lirzin wrote:
> >
> > > It is often easier to write expected-to-fail tests this way (so
> > that
> > > they can all look the same), rather than have to have, for
> > exa
Reuben Thomas writes:
> On 19 May 2016 at 00:04, Mathieu Lirzin wrote:
>
> > It is often easier to write expected-to-fail tests this way (so
> that
> > they can all look the same), rather than have to have, for
> example, an
> > extra driver that converts expected errors into
On 20 May 2016 at 15:58, Gavin Smith wrote:
> On 19 May 2016 at 00:04, Mathieu Lirzin wrote:
> >> It is often easier to write expected-to-fail tests this way (so that
> >> they can all look the same), rather than have to have, for example, an
> >> extra driver that converts expected errors into
On 19 May 2016 at 00:04, Mathieu Lirzin wrote:
>> It is often easier to write expected-to-fail tests this way (so that
>> they can all look the same), rather than have to have, for example, an
>> extra driver that converts expected errors into success codes for the
>> automake test harness.
>
> Wh
On 19 May 2016 at 00:55, Peter Johansson wrote:
>
>
> On 05/19/2016 09:04 AM, Mathieu Lirzin wrote:
>
>> Another common use for "expected failure" is to write tests to check
>>> >that error conditions arise as expected, for example, by checking that
>>> >a program raises an error when given inval
On 19 May 2016 at 00:04, Mathieu Lirzin wrote:
> > It is often easier to write expected-to-fail tests this way (so that
> > they can all look the same), rather than have to have, for example, an
> > extra driver that converts expected errors into success codes for the
> > automake test harness.
>
On 05/19/2016 09:04 AM, Mathieu Lirzin wrote:
Another common use for "expected failure" is to write tests to check
>that error conditions arise as expected, for example, by checking that
>a program raises an error when given invalid input.
I agree that XFAIL can be ambiguous, however I think t
Hi,
Reuben Thomas writes:
> The documentation says: "It's not uncommon, especially during early
> development stages, that some tests fail for known reasons, and that
> the developer doesn't want
> to tackle these failures immediately (this is especially true when the
> failing tests deal with c
The documentation says: "It's not uncommon, especially during early
development stages, that some tests fail for known reasons, and that the
developer doesn't want
to tackle these failures immediately (this is especially true when the
failing tests deal with corner cases)."
Another common use for
