You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Anton Luht <an...@gmail.com> on 2006/06/01 13:34:51 UTC
[testing] Re: AWT, Java2D and SWING contribution
Hello,
Some time ago I've read in Danese Cooper's blog that Sun doesn't have
compatibility tests for Swing/AWT. I think it means that there are no
such tests in other companies or projects as well. We can see if our
implementation is compatible with Sun's only by launching some
application on both and comparing.
Of course it's difficult to test view automatically - that button with
some text really shows the text and looks nice or that green is green
or that grid table is a grid table. What can be automatically tested
is model:
- if one of button's properties changed, others are changed accordingly
- if a component changes state, listeners are notified properly
- repaint() and revalidate() called where needed, etc.
Maybe some of these scenarios can be tested even in headless mode -
without displaying anything.
What do you think - does this testing approach make sense? Is there a
need in such tests to ensure confidence that our libraries are
compatible? Or we'll just try different applications and solve
problems as they arise?
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing] Re: AWT, Java2D and SWING contribution
Posted by Anton Avtamonov <an...@gmail.com>.
On 6/1/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 1 June 2006 at 17:36, "Alexey Petrenko" <al...@gmail.com>
> wrote:
> >
> > Which thing will this tool compare? Created windows or displays pixel
> > by pixel?
>
> The syntax I listed for xwd dumps the whole virtual display. You can
> also instruct it to dump single windows. But either way, it's a pixel
> by pixel dump which is why I said that doing something meaningful in
> step 4 - the comparison - would be the hard part.
Very hard part. Colors used in Harmony are not equivalent to RI.
Therefore I expect that "as is" comparison will show that everything
is different :-). The entire component Look is not 100% copied, i.e.
position of the focus frame, look of the borders, etc. differ.
Besides, colors are theme-dependent and may differ for MetalTheme and
OceanTheme, for instance.
That's why I suppose that using of some heuristical rules will be
required. Like "button is in pressed state if its color became
darker".
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing] Re: AWT, Java2D and SWING contribution
Posted by Alexey Petrenko <al...@gmail.com>.
Which thing will this tool compare? Created windows or displays pixel by pixel?
2006/6/1, Mark Hindess <ma...@googlemail.com>:
>
> On 1 June 2006 at 14:19, Chris Gray <ch...@kiffer.be> wrote:
> > I believe that Classpath uses the VisualTestEngine we developed at Acunia.
> > Requires manual operation, but it has facilities for explanatory texts, pass/
> > fail indications, etc.. It will even run applets if you ask it nicely. You
> > can find it in the SVN repository at www.wonka-vm.org (which is down at the
> > moment I write this, I'll ping Luminis to ask why).
> >
> > I don't think it's that difficult to hack X to write to normal RAM
> > instead of a framebuffer, but the real problem is that there's no hard
> > spec of which pixels should change to what colour when you create e.g.
> > a button. You could instrument an X server in other ways though, for
> > example to see that [J]Frame actually opens a new window and sets its
> > title.
>
> I don't think you even need to hack X.
>
> Simplest way to do a perfect comparison that springs to mind is:
>
> 1) Start an X virtual framebuffer on display :1, with:
>
> Xvfb :1 &
>
> 2) run RI test, using DISPLAY=:1, periodically taking snapshots[0] with:
>
> xwd -display :1 -root -out NN.xwd
>
> 3) repeat the tests with harmony
>
> 4) compare the resulting *.xwd files
>
> The hard part would be to elaborate on step 4 to support minor
> variations in the comparison process.
>
> If you were comparing manual/visually, ImageMagick does quite a good job
> with:
>
> compare ri.xwd hy.xwd :x
>
> If I recall correctly difference tend to be shown in bright red.
>
> Regards,
> Mark
>
> [0] I mean instrument the tests with calls to do this.
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing] Re: AWT, Java2D and SWING contribution
Posted by Anton Avtamonov <an...@gmail.com>.
On 6/1/06, Chris Gray <ch...@kiffer.be> wrote:
> I believe that Classpath uses the VisualTestEngine we developed at Acunia.
> Requires manual operation, but it has facilities for explanatory texts, pass/
> fail indications, etc.. It will even run applets if you ask it nicely. You
> can find it in the SVN repository at www.wonka-vm.org (which is down at the
> moment I write this, I'll ping Luminis to ask why).
>
> I don't think it's that difficult to hack X to write to normal RAM instead of
> a framebuffer, but the real problem is that there's no hard spec of which
> pixels should change to what colour when you create e.g. a button. You could
> instrument an X server in other ways though, for example to see that [J]Frame
> actually opens a new window and sets its title.
Well, IMHO it is not reuiqred to test every pixel. What is important
for visual testing of JButton say it to check that it change its color
being pressed, for instance. Or that focus is displayed. I believe we
could figure out not very complicated heuristics to identify different
states for each component.
I expect Swing testing is based on real applications and use some tool
to automate scenarious and automatically check the results (compoennt
states) basing on the choosen heuristics.
Wishes,
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing] Re: AWT, Java2D and SWING contribution
Posted by Chris Gray <ch...@kiffer.be>.
I believe that Classpath uses the VisualTestEngine we developed at Acunia.
Requires manual operation, but it has facilities for explanatory texts, pass/
fail indications, etc.. It will even run applets if you ask it nicely. You
can find it in the SVN repository at www.wonka-vm.org (which is down at the
moment I write this, I'll ping Luminis to ask why).
I don't think it's that difficult to hack X to write to normal RAM instead of
a framebuffer, but the real problem is that there's no hard spec of which
pixels should change to what colour when you create e.g. a button. You could
instrument an X server in other ways though, for example to see that [J]Frame
actually opens a new window and sets its title.
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [testing] Re: AWT, Java2D and SWING contribution
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Anton Luht wrote:
> Hello,
>
> Some time ago I've read in Danese Cooper's blog that Sun doesn't have
> compatibility tests for Swing/AWT. I think it means that there are no
> such tests in other companies or projects as well. We can see if our
> implementation is compatible with Sun's only by launching some
> application on both and comparing.
Two things :
1) I'm not convinced that Danese is right here - if someone wants to
look at the JCK from Sun (it's available somewhere under a read-only, no
compiling, no running, no nothing license) we can verify, but I actually
am not too concerned. We'll pass the JCK (TCK) no matter what tests are
or are not in there.
2) Compatibility is determined formally by the JCK. Running
applications an comparing is a help for us, but doesn't allow us to make
any claims regarding compatibility.
>
> Of course it's difficult to test view automatically - that button with
> some text really shows the text and looks nice or that green is green
> or that grid table is a grid table. What can be automatically tested
> is model:
>
> - if one of button's properties changed, others are changed accordingly
> - if a component changes state, listeners are notified properly
> - repaint() and revalidate() called where needed, etc.
>
> Maybe some of these scenarios can be tested even in headless mode -
> without displaying anything.
>
> What do you think - does this testing approach make sense? Is there a
> need in such tests to ensure confidence that our libraries are
> compatible? Or we'll just try different applications and solve
> problems as they arise?
I certainly think that tests are good here, of any sort. Better some
than nothing.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org