You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metamodel.apache.org by Tomasz Guziałek <to...@apache.org> on 2015/11/28 10:31:57 UTC
[DISCUSS] Checking-in "red" unit tests reproducing bugs.
Hello everyone,
I would like to discuss with you what would be the preferred way to
checking-in code that is a unit test reproducing an issue, but not fixing
it.
I created branches in my own fork of MetaModel with failing unit tests for
several tickets. Currently only one of them is still open and no fix is on
the way:
https://issues.apache.org/jira/browse/METAMODEL-167
Such branches should not be merged into master as the build will fail, but
they are a valuable documentation of the issues. As mentioned, the branches
live only in a fork, but maybe we should consider checking-in them into the
main repo?
I am starting the discussion right now, because I would like to nuke my own
fork soon. I made some commits on my fork's master branch by mistake and it
keeps polluting subsequent branches I create. I know that is probably
killing the fly with a bazooka, but it will save me much time carefully
fixing the mess.
I would love to hear your suggestions regarding the process how we deal
with "red" branches in MetaModel - no doubt that the situatio of
reproducing bugs with unit tests will come up again in the nearest future.
Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
Posted by Alberto Rodriguez <ar...@stratio.com>.
In Scala, the test frameworks allow you to include a "pendingUntilFixed"
annotation [1]. IMHO this is a really good way to check-in tests that are
still pending.
Not sure how to mimic this behaviour with plain junit though :(
[1]
https://etorreborre.github.io/specs2/guide/SPECS2-3.5/org.specs2.guide.PendingUntilFixedExamples.html
Alberto Rodriguez
Vía de las dos Castillas, 33, Ática 4, 3ª Planta
28224 Pozuelo de Alarcón, Madrid
Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
<https://twitter.com/StratioBD>*
2015-11-29 11:53 GMT+01:00 Tomasz Guziałek <to...@guzialek.info>:
> I personally don't like working with diffs. But will try to make friends
> with them, sounds like a reasonable idea to use them for bug reproducing
> purposes.
>
> Pozdrawiam / Regards / Med venlig hilsen
> Tomasz Guziałek
>
> 2015-11-29 9:30 GMT+01:00 Kasper Sørensen <i.am.kasper.sorensen@gmail.com
> >:
>
> > I think that also sounds like a good idea. Agree that rarely the branch
> is
> > needed.
> >
> > 2015-11-28 13:09 GMT+01:00 Du Krøger, Dennis <
> > Dennis.DuKroger@humaninference.com>:
> >
> > > Hmmm... How about just attaching it as a diff to the related issue
> > > description?
> > >
> > > Since there is no actual functionality, "only" a demonstration of a
> > > problem, I'm not sure a branch is the best place to keep these.
> > >
> > > /Dennis
> > > ________________________________________
> > > From: Kasper Sørensen <i....@gmail.com>
> > > Sent: Saturday, November 28, 2015 10:42
> > > To: dev@metamodel.apache.org
> > > Subject: Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
> > >
> > > Good discussion point Tomasz. From my point of view, it is very nice to
> > > reproduce a bug with a unittest. If it is trivial I usually simply
> inline
> > > the unittest in the JIRA issue in a {code} block. But for committers
> it's
> > > certainly also possible that we create branches on the central/shared
> > repo.
> > > I agree that creating such a branch on a fork is a bit messy in the
> long
> > > run. Regardless how it's done - I think demonstrating a bug with a
> > failing
> > > unittest is a great practice and we should encourage that a lot. I
> would
> > be
> > > happy to agree on making it standard practice to make remote branches
> on
> > > the MM central git repo to represent such bug tests. Maybe we should
> just
> > > always prefix such branch names with "bug/..." or something like that.
> > >
> > > 2015-11-28 10:31 GMT+01:00 Tomasz Guziałek <tomaszguzialek@apache.org
> >:
> > >
> > > > Hello everyone,
> > > >
> > > > I would like to discuss with you what would be the preferred way to
> > > > checking-in code that is a unit test reproducing an issue, but not
> > fixing
> > > > it.
> > > >
> > > > I created branches in my own fork of MetaModel with failing unit
> tests
> > > for
> > > > several tickets. Currently only one of them is still open and no fix
> is
> > > on
> > > > the way:
> > > > https://issues.apache.org/jira/browse/METAMODEL-167
> > > >
> > > > Such branches should not be merged into master as the build will
> fail,
> > > but
> > > > they are a valuable documentation of the issues. As mentioned, the
> > > branches
> > > > live only in a fork, but maybe we should consider checking-in them
> into
> > > the
> > > > main repo?
> > > >
> > > > I am starting the discussion right now, because I would like to nuke
> my
> > > own
> > > > fork soon. I made some commits on my fork's master branch by mistake
> > and
> > > it
> > > > keeps polluting subsequent branches I create. I know that is probably
> > > > killing the fly with a bazooka, but it will save me much time
> carefully
> > > > fixing the mess.
> > > >
> > > > I would love to hear your suggestions regarding the process how we
> deal
> > > > with "red" branches in MetaModel - no doubt that the situatio of
> > > > reproducing bugs with unit tests will come up again in the nearest
> > > future.
> > > >
> > >
> >
>
Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
Posted by Tomasz Guziałek <to...@guzialek.info>.
I personally don't like working with diffs. But will try to make friends
with them, sounds like a reasonable idea to use them for bug reproducing
purposes.
Pozdrawiam / Regards / Med venlig hilsen
Tomasz Guziałek
2015-11-29 9:30 GMT+01:00 Kasper Sørensen <i....@gmail.com>:
> I think that also sounds like a good idea. Agree that rarely the branch is
> needed.
>
> 2015-11-28 13:09 GMT+01:00 Du Krøger, Dennis <
> Dennis.DuKroger@humaninference.com>:
>
> > Hmmm... How about just attaching it as a diff to the related issue
> > description?
> >
> > Since there is no actual functionality, "only" a demonstration of a
> > problem, I'm not sure a branch is the best place to keep these.
> >
> > /Dennis
> > ________________________________________
> > From: Kasper Sørensen <i....@gmail.com>
> > Sent: Saturday, November 28, 2015 10:42
> > To: dev@metamodel.apache.org
> > Subject: Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
> >
> > Good discussion point Tomasz. From my point of view, it is very nice to
> > reproduce a bug with a unittest. If it is trivial I usually simply inline
> > the unittest in the JIRA issue in a {code} block. But for committers it's
> > certainly also possible that we create branches on the central/shared
> repo.
> > I agree that creating such a branch on a fork is a bit messy in the long
> > run. Regardless how it's done - I think demonstrating a bug with a
> failing
> > unittest is a great practice and we should encourage that a lot. I would
> be
> > happy to agree on making it standard practice to make remote branches on
> > the MM central git repo to represent such bug tests. Maybe we should just
> > always prefix such branch names with "bug/..." or something like that.
> >
> > 2015-11-28 10:31 GMT+01:00 Tomasz Guziałek <to...@apache.org>:
> >
> > > Hello everyone,
> > >
> > > I would like to discuss with you what would be the preferred way to
> > > checking-in code that is a unit test reproducing an issue, but not
> fixing
> > > it.
> > >
> > > I created branches in my own fork of MetaModel with failing unit tests
> > for
> > > several tickets. Currently only one of them is still open and no fix is
> > on
> > > the way:
> > > https://issues.apache.org/jira/browse/METAMODEL-167
> > >
> > > Such branches should not be merged into master as the build will fail,
> > but
> > > they are a valuable documentation of the issues. As mentioned, the
> > branches
> > > live only in a fork, but maybe we should consider checking-in them into
> > the
> > > main repo?
> > >
> > > I am starting the discussion right now, because I would like to nuke my
> > own
> > > fork soon. I made some commits on my fork's master branch by mistake
> and
> > it
> > > keeps polluting subsequent branches I create. I know that is probably
> > > killing the fly with a bazooka, but it will save me much time carefully
> > > fixing the mess.
> > >
> > > I would love to hear your suggestions regarding the process how we deal
> > > with "red" branches in MetaModel - no doubt that the situatio of
> > > reproducing bugs with unit tests will come up again in the nearest
> > future.
> > >
> >
>
Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
Posted by Kasper Sørensen <i....@gmail.com>.
I think that also sounds like a good idea. Agree that rarely the branch is
needed.
2015-11-28 13:09 GMT+01:00 Du Krøger, Dennis <
Dennis.DuKroger@humaninference.com>:
> Hmmm... How about just attaching it as a diff to the related issue
> description?
>
> Since there is no actual functionality, "only" a demonstration of a
> problem, I'm not sure a branch is the best place to keep these.
>
> /Dennis
> ________________________________________
> From: Kasper Sørensen <i....@gmail.com>
> Sent: Saturday, November 28, 2015 10:42
> To: dev@metamodel.apache.org
> Subject: Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
>
> Good discussion point Tomasz. From my point of view, it is very nice to
> reproduce a bug with a unittest. If it is trivial I usually simply inline
> the unittest in the JIRA issue in a {code} block. But for committers it's
> certainly also possible that we create branches on the central/shared repo.
> I agree that creating such a branch on a fork is a bit messy in the long
> run. Regardless how it's done - I think demonstrating a bug with a failing
> unittest is a great practice and we should encourage that a lot. I would be
> happy to agree on making it standard practice to make remote branches on
> the MM central git repo to represent such bug tests. Maybe we should just
> always prefix such branch names with "bug/..." or something like that.
>
> 2015-11-28 10:31 GMT+01:00 Tomasz Guziałek <to...@apache.org>:
>
> > Hello everyone,
> >
> > I would like to discuss with you what would be the preferred way to
> > checking-in code that is a unit test reproducing an issue, but not fixing
> > it.
> >
> > I created branches in my own fork of MetaModel with failing unit tests
> for
> > several tickets. Currently only one of them is still open and no fix is
> on
> > the way:
> > https://issues.apache.org/jira/browse/METAMODEL-167
> >
> > Such branches should not be merged into master as the build will fail,
> but
> > they are a valuable documentation of the issues. As mentioned, the
> branches
> > live only in a fork, but maybe we should consider checking-in them into
> the
> > main repo?
> >
> > I am starting the discussion right now, because I would like to nuke my
> own
> > fork soon. I made some commits on my fork's master branch by mistake and
> it
> > keeps polluting subsequent branches I create. I know that is probably
> > killing the fly with a bazooka, but it will save me much time carefully
> > fixing the mess.
> >
> > I would love to hear your suggestions regarding the process how we deal
> > with "red" branches in MetaModel - no doubt that the situatio of
> > reproducing bugs with unit tests will come up again in the nearest
> future.
> >
>
Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
Posted by Du,
Dennis <De...@HumanInference.com>.
Hmmm... How about just attaching it as a diff to the related issue description?
Since there is no actual functionality, "only" a demonstration of a problem, I'm not sure a branch is the best place to keep these.
/Dennis
________________________________________
From: Kasper Sørensen <i....@gmail.com>
Sent: Saturday, November 28, 2015 10:42
To: dev@metamodel.apache.org
Subject: Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
Good discussion point Tomasz. From my point of view, it is very nice to
reproduce a bug with a unittest. If it is trivial I usually simply inline
the unittest in the JIRA issue in a {code} block. But for committers it's
certainly also possible that we create branches on the central/shared repo.
I agree that creating such a branch on a fork is a bit messy in the long
run. Regardless how it's done - I think demonstrating a bug with a failing
unittest is a great practice and we should encourage that a lot. I would be
happy to agree on making it standard practice to make remote branches on
the MM central git repo to represent such bug tests. Maybe we should just
always prefix such branch names with "bug/..." or something like that.
2015-11-28 10:31 GMT+01:00 Tomasz Guziałek <to...@apache.org>:
> Hello everyone,
>
> I would like to discuss with you what would be the preferred way to
> checking-in code that is a unit test reproducing an issue, but not fixing
> it.
>
> I created branches in my own fork of MetaModel with failing unit tests for
> several tickets. Currently only one of them is still open and no fix is on
> the way:
> https://issues.apache.org/jira/browse/METAMODEL-167
>
> Such branches should not be merged into master as the build will fail, but
> they are a valuable documentation of the issues. As mentioned, the branches
> live only in a fork, but maybe we should consider checking-in them into the
> main repo?
>
> I am starting the discussion right now, because I would like to nuke my own
> fork soon. I made some commits on my fork's master branch by mistake and it
> keeps polluting subsequent branches I create. I know that is probably
> killing the fly with a bazooka, but it will save me much time carefully
> fixing the mess.
>
> I would love to hear your suggestions regarding the process how we deal
> with "red" branches in MetaModel - no doubt that the situatio of
> reproducing bugs with unit tests will come up again in the nearest future.
>
Re: [DISCUSS] Checking-in "red" unit tests reproducing bugs.
Posted by Kasper Sørensen <i....@gmail.com>.
Good discussion point Tomasz. From my point of view, it is very nice to
reproduce a bug with a unittest. If it is trivial I usually simply inline
the unittest in the JIRA issue in a {code} block. But for committers it's
certainly also possible that we create branches on the central/shared repo.
I agree that creating such a branch on a fork is a bit messy in the long
run. Regardless how it's done - I think demonstrating a bug with a failing
unittest is a great practice and we should encourage that a lot. I would be
happy to agree on making it standard practice to make remote branches on
the MM central git repo to represent such bug tests. Maybe we should just
always prefix such branch names with "bug/..." or something like that.
2015-11-28 10:31 GMT+01:00 Tomasz Guziałek <to...@apache.org>:
> Hello everyone,
>
> I would like to discuss with you what would be the preferred way to
> checking-in code that is a unit test reproducing an issue, but not fixing
> it.
>
> I created branches in my own fork of MetaModel with failing unit tests for
> several tickets. Currently only one of them is still open and no fix is on
> the way:
> https://issues.apache.org/jira/browse/METAMODEL-167
>
> Such branches should not be merged into master as the build will fail, but
> they are a valuable documentation of the issues. As mentioned, the branches
> live only in a fork, but maybe we should consider checking-in them into the
> main repo?
>
> I am starting the discussion right now, because I would like to nuke my own
> fork soon. I made some commits on my fork's master branch by mistake and it
> keeps polluting subsequent branches I create. I know that is probably
> killing the fly with a bazooka, but it will save me much time carefully
> fixing the mess.
>
> I would love to hear your suggestions regarding the process how we deal
> with "red" branches in MetaModel - no doubt that the situatio of
> reproducing bugs with unit tests will come up again in the nearest future.
>