harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [classlib][accessibility] isolating tests (WAS: [classlib][tests] Refactoring breakage)
Date Wed, 29 Nov 2006 05:15:59 GMT
Removing the dependency was more trivial than I expected, so I just
went ahead and committed it.

There were only three pieces of functionality being used, neither of
which had any relation to Swing.
* Exception testing - rather than using a try with a fail if no
exception, an exception test method and a exception runner class were
being used. This little framework is embedded into the
BasicSwingTestCase.
* PropertyChangeListener impl - the BasicSwingTestCase has a utility
implementation of a beans PropertyChangeListener that a test was using
to assert change events.
* isHarmony() checks - There were a handful of places performing
isHarmony checks, but everyone of the tests fails on an RI even with
these checks, so it wasn't serving much of purpose.

TODO - What I did notice with these tests is that many of them make
assumes about class fields being package-private and asserting
conditions directly against the fields. This compiles and works
against Harmony, but doesn't compile or work against any RI. This
should probably be cleaned up, so that the tests are asserting the
public contracts.

-Nathan

On 11/28/06, Nathan Beyer <nbeyer@gmail.com> wrote:
> Does anyone have any concerns or thoughts on rewriting the
> 'accessiblity' modules tests so that they don't depend on the
> BasicSwingTestCase?
>
> -Nathan
>
> ---------- Forwarded message ----------
> From: Nathan Beyer <nbeyer@gmail.com>
> Date: Nov 28, 2006 8:23 PM
> Subject: Re: [classlib][tests] Refactoring breakage
> To: dev@harmony.apache.org
>
> After looking through the logs. It seems these 'accessibility' tests
> were just added around Aug 3rd. The Eclipse IDE artifacts aren't even
> updated to reflect their existence. Prior to this the tests were in
> the "awt_swing_modules".
>
> Looking at the tests, most of them don't even use the functionality in
> the BasicSwingTestCase. Some do use a few of the inner classes of
> BasicSwingTestCase, but these should really be factored out, as they
> are completely independent. I'm going to go through these tests and
> clean them up to be as isolated as the module is.
>
> Also, the 'support' project's manifest isn't exporting all of the it's
> packagings, so the other project's can't see the classes, at least
> within the Eclipse IDE. If the OSGi manifests and the Eclipse
> artifacts aren't going to be maintained, should we just get rid of
> them? The only place they are used is inside of Eclipse for
> developers.
>
> -Nathan
>
> On 11/28/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > Stepan Mishura wrote:
> > > On 11/28/06, Tim Ellison wrote:
> > >>
> > >> Stepan Mishura wrote:
> > >> > I agree with moving it back to 'support'. Tim, are you working on
this
> > >> > (just to avoid duplicate work)?
> > >>
> > >> No I'm not.  I was going to let Nathan comment, and if necessary fix,
> > >> since he made the change.  If it is a blocker that cannot wait for the
> > >> next couple of hours then you/I/anyone can take a look at it.
> > >
> > > I'd consider it as a blocker cause the classlib build is broken.
> >
> > Ok, I'll fix it.  It will take 40 mins or so because I'll have to run
> > all the tests again (hint, hint :-) )
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>

Mime
View raw message