RE: [cdt-dev] Aboud content assist failures and committing failingJunit

[Andrew Niefer <aniefer@xxxxxxxxxx>]

I of course meant org.eclipse.cdt.core.tests.FailingTest

-Andrew

Andrew Niefer/Ottawa/IBM@IBMCA
Sent by: cdt-dev-bounces@xxxxxxxxxxx

07/14/2006 10:31 AM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	RE: [cdt-dev] Aboud content assist failures and        committing        failingJunit tests

Look at the class org.eclipse.cdt.core.FailingTest & its references.
 We started using this in the core for tests we knew failed.

It wraps a failing test and passes when the inner test fails.  Its
use is not very widespread, but I would suggest something like this is
a good solution to the problem of known failures. 

-Andrew

"Leherbauer, Anton" <Anton.Leherbauer@xxxxxxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

07/14/2006 08:46 AM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	RE: [cdt-dev] Aboud content assist failures and committing        failingJunit tests

I'd rather go for 1b and 2b, although if the category 2 
tests all share the same reason why they are failing,
then one bugzilla for this reason should do it.

And I would vote for adding the tests to the nightly builds!

My 2 Euro Cents.

Toni

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ploett, Norbert
> Sent: Friday, July 14, 2006 1:30 PM
> To: CDT General developers list.
> Subject: [cdt-dev] Aboud content assist failures and 
> committing failingJunit tests
> 
> Hi folks,
> 
> so I ported a number of Junits for the content assist 
> processor over to
> the new CCompletionProcessor2 and they generally fall into 2 
> categories:
> 
> 1) After the port the tests can be made to work reasonably, there
are
> minor deviations from the expected results.
> 
> 2) The completion processor cannot create a completion node at all.
> 
> For category 1) I commited these tests to the repository, they can
be
> found in package org.eclipse.cdt.ui.tests.text.contentassist2. I made
> verbose comments, describing the deviations, but twisted the code
so
> that the tests shall be green when they are run. The clean 
> way would be
> to let the tests be red and create bugzilla entries describing the
> problems. But I was shy to commit test code that would fail.
> 
> For category 2) I did not yet commit these because they fail so badly,
> and, as above, I did not want to commit failing tests. I do not think
> that I will be able to repair the deficiencies on my own, for 
> the moment
> I can just be the supplier of well-documented bug reports.
> 
> 
> Here are some alternatives of what I could do next:
> 
> Category 1 failures:
> a) Create bugzillas for the category 1 failures, but leave the code
so
> that the tests remain green.
> b) Create bugzillas for the category 1 failures, and make the tests
> actually fail until the completion processor and it's subsidaries
are
> repaired.
> 
> Category 2 failures:
> a) Create bugzillas for the category 2 failures, with the 
> test case code
> attached, but not commit the code to the repository.
> b) Create bugzillas for the category 2 failures, and commit 
> them to the
> repository.
> 
> ... and the final big question: Should the tests in
> org.eclipse.cdt.ui.tests, including my content assist stuff, 
> be added to
> the nightly build tests? (See also my earlier email of today for this
> subject)
> 
> Thanks for opinions
> 
> 
> Norbert Ploett
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev