git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Loeliger <jdl@freescale.com>
To: Jan Hudec <bulb@ucw.cz>
Cc: Junio C Hamano <gitster@pobox.com>,
	Martin Langhoff <martin.langhoff@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [RFC] git integrated bugtracking
Date: Mon, 11 Jun 2007 13:51:32 -0500	[thread overview]
Message-ID: <1181587892.3380.37.camel@ld0161-tx32> (raw)
In-Reply-To: <20070610085044.GD4084@efreet.light.src>

On Sun, 2007-06-10 at 03:50, Jan Hudec wrote:

> 
> It would be really useful to have a tool, that could link a bug report to
> a test case demonstrating it and reporting whenever output of that test case
> changes. This would make it much easier for developer to see which bugs he
> might have fixed when doing a refactoring.

I think the inverse is interesting too.  That is, applying
keywords to tests and then making the test database
keywords searchable.

I used to work for a company that had a huge collection
of test cases for its product.  It would take days to run
a validation run for some of the simplest of changes that
were introduced during development.

Often what I wanted, and what was needed, was a simple
sanity check that verified that the proposed change was
not brain-dead from the start.

Over time, I found that certain tests proved to be good
at detecting failures in particular portions of the code.
Often, that test was not necessarily directly related to
the concept it was _supposed_ to be designed to test, but
incidentally was good at some _other_ concept too.

The developer who made the change, and ran the tests,
then was able to state "Test t42 from suite Frotz is good
at detecting changes to the <SomeModule>."

The trick is to now associate with that test the keyword
"SomeModule" so that in the future, another developer
could ask:  "Say, I just modified <SomeModule>, are there
any tests that are good at proving my changes sound?"
A test driver could then focus some test cycles quickly.

Now, for git, it's not likely a problem to just run
through all of its tests.  At ${PriorCompany} it was
essential to pare down the test suites to a manageable
size, yet still have assurance that your coverage was
reasonably good.

jdl

  reply	other threads:[~2007-06-11 18:53 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-03 11:48 [RFC] git integrated bugtracking Pierre Habouzit
2007-06-03 12:35 ` Yann Dirson
2007-06-03 13:23   ` Pierre Habouzit
2007-06-03 12:59 ` Michael Poole
2007-06-03 13:31   ` Pierre Habouzit
2007-06-03 13:48     ` Johan Herland
2007-06-03 15:19       ` Pierre Habouzit
2007-06-03 15:44         ` Matthieu Moy
2007-06-03 16:07           ` Pierre Habouzit
2007-06-03 17:35             ` david
2007-06-03 18:49               ` Pierre Habouzit
2007-06-03 19:07                 ` david
2007-06-03 20:31                   ` Yann Dirson
2007-06-03 17:10         ` Yann Dirson
2007-06-03 20:04         ` Yann Dirson
2007-06-03 20:21           ` Pierre Habouzit
2007-06-04 22:03         ` Yann Dirson
2007-06-04 22:25           ` Pierre Habouzit
2007-06-03 19:22 ` Linus Torvalds
2007-06-03 20:16   ` Pierre Habouzit
2007-06-03 23:07     ` Martin Waitz
2007-06-04  9:32       ` Rogan Dawes
     [not found]         ` <20070604102037.GB7758@.intersec.eu>
2007-06-04 13:29           ` Rogan Dawes
2007-06-03 20:17   ` Yann Dirson
2007-06-03 20:32     ` Pierre Habouzit
2007-06-09 12:12 ` Pierre Habouzit
2007-06-09 16:23   ` Jakub Narebski
2007-06-10  2:44   ` Daniel Barkalow
2007-06-10  7:44     ` Johannes Schindelin
2007-06-10  6:59   ` Martin Langhoff
2007-06-10  7:35     ` Junio C Hamano
2007-06-10  8:38       ` Martin Langhoff
2007-06-10  8:50       ` Jan Hudec
2007-06-11 18:51         ` Jon Loeliger [this message]
2007-06-12  8:54           ` Guilhem Bonnefille
2007-06-10  8:37     ` Jan Hudec
2007-06-10  8:55       ` Martin Langhoff
2007-06-10 10:16         ` Pierre Habouzit
2007-06-10 23:14           ` Martin Langhoff
2007-06-11  8:45             ` Pierre Habouzit
2007-06-11 10:00               ` Martin Langhoff
2007-06-10 10:49         ` Jan Hudec
2007-06-10 22:07       ` Matthieu Moy
2007-06-10 13:34     ` Pierre Habouzit
2007-06-10 13:43     ` Pierre Habouzit
2007-06-10 14:02     ` Pierre Habouzit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1181587892.3380.37.camel@ld0161-tx32 \
    --to=jdl@freescale.com \
    --cc=bulb@ucw.cz \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.langhoff@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).