git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [JGIT PATCH 8/6] Fix zero context insert and delete hunk headers to match CGit

From
SZEDER Gábor <szeder@ira.uka.de>
Date
May 5, 2009, 22:19 UTC
Message-ID
<20090505221946.GA20002@neumann>
In-Reply-To
<200905031124.08113.robin.rosenberg.lists@dewire.com>
Hi,
On Sun, May 03, 2009 at 11:24:07AM +0200, Robin Rosenberg wrote:
Show 28 quoted lines
> söndag 03 maj 2009 10:31:30 skrev "Ferry Huberts (Pelagic)" <ferry.huberts@pelagic.nl>:
> > > 3) We should have a convention like C Git for marking known breakages.
> > > One option is FIXME, another it so go JUnit 4 and abuse the expected exception 
> > > annotation (using it for declaring OK exceptions is pretty bad use anyway I think,
> > > so we might use it for something better), or perhaps the @Ignore annotation which
> > > is meant specifically for this and other cases. A FIXME can be implemented right
> > > away.
> > 
> > standard pratice for junit would be to write a test case on what you would 
> > expect to be _correct_ behaviour. obviously that test would then fail.
> > it would be a know failure in the test suite. do not go ignoring it. it's 
> > better to keep being reminded that stuff doesn't work :-)
> 
> What I've see so far is that people start ignoring almost any failure, including new ones, when the test suites contains fails with "known" failues. The assumption is that the failed tests were the same as before.
> 
> Worse, automated tests have a hard time telling the difference. Currently I ran
> the jgit tests as part of the Eclipse plugin build and I want it to stop if there is a problem that we don't know of. 
> 
> "Annotation" of different kinds can be "grepped" for so we can find the broken
> cases separately and even refuse completion of release builds if we decide
> on that. 
> 
> Our primary UI right now is the Eclipse JUnit tests runner and I don't want
> to be remined of Shawn's or whoever's bugs when trying to make sure I don't
> break anything. Red = *I* broke something or found something new. 
> 
> TestNG has a nice way of classifying tests so, we could mark failures as "known failures" and specifically exclude/include them when invoking the
> JUnit tests.

you could use test suites to easily circumvent this in JUnit, even in JUnit 3.x.

Just set up two test suites: one for the tests that should pass and one for the tests with known breakages. That way you can run either only the "good" tests or only the broken ones. Or even both, and you can easily discern failures caused by known breakages from your new breakages by looking at the tree of tests in eclipse's JUnit view.

Regards, Gábor

Previous: Ferry Huberts (Pelagic)
Message 8 of 8 in “BROKEN: Add a zero line context test for diff.DiffFormatter”
  1. 7/6 BROKEN: Add a zero line context test for diff.DiffFormatterShawn O. Pearce, May 3, 2009
  2. 8/6 Fix zero context insert and delete hunk headers to match CGitShawn O. Pearce, May 3, 2009
  3. Miles BaderMay 3, 2009
  4. Robin RosenbergMay 3, 2009
  5. Ferry Huberts (Pelagic)May 3, 2009
  6. Robin RosenbergMay 3, 2009
  7. Ferry Huberts (Pelagic)May 3, 2009
  8. SZEDER GáborMay 5, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.