[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] {master} Improve and extend tests on `:=' variable assignmen
From: |
Stefano Lattarini |
Subject: |
Re: [PATCH] {master} Improve and extend tests on `:=' variable assignments. |
Date: |
Wed, 1 Dec 2010 16:58:21 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
On Monday 29 November 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Mon, Nov 29, 2010 at 09:09:59PM CET:
> > On Monday 29 November 2010, Ralf Wildenhues wrote:
> > > I approve the patch but ask you to keep that coverage in, now you update
> > > the patch with an unrelated new change whose applicability depends on
> > > completely different factors (namely deciding whether some behavior is
> > > desirable or not),
> > >
> > Why should its applicatibility depend on such a decision? The testcase
> > just serves to expose the current behaviour explicitly, without telling
> > if it's desirable or not.
>
> IMVHO an entry in the bug tracker is more applicable for issues that may
> be valid or invalid.
>
You're right that an xfailing testcase without an associated PR might
be mostly useless (so yes, my bad in this case too, for proposing a new
xfailing test without opening an associated PR first). Notice that,
IMHO, the best thing to do is to get both a PR and a testcase, e.g. as
follows:
- open a new PR in the bug tracker;
- add xfailing testcase(s), which can now point to an archived PR
(thus rendering the test much more useful, and its purpose more
clear);
- maybe update the PR to refer to the xfailing testcase(s).
> A commit adding a test that is later removed
> because it's invalid is not so easily searched for a couple of years
> later. Closed PRs on the other hand are straightforward to search.
>
This is a very good point in favor of the opening of a PR in the bug
tracker, but IMO it's not a reason not to have *also* an xfailing
testcase.
Regards,
Stefano
- Re: [PATCH] {master} Improve and extend tests on `:=' variable assignments.,
Stefano Lattarini <=