Is there a way to simulate a Tab key? I looked at the Key class, but
did not see anything there.

Thanks.

Hi Nascif,

On Tue, 09 Aug 2005 01:08:55 +0200, Nascif Abousalh-Neto
<Nascif.AbousalhNeto@...> wrote:
>> [...] Is that a means for replacing the generated JAR ?
> Yes. You would give up the compile-time checking for some run-time
> flexibility. Basically you would add to Panel a generic method called
>
>   UIComponent getUIComponent(String className)

As of release 0.11, there is a "UIComponent findComponent(Class
uiComponentClass)" method on Panel which can do just that. However, there
is no need for a config file - we expect the uiComponentClass to have a
static SWING_CLASSES field listing the corresponding Swing classes.


> The test code would be a little less clean, [...]

Yes, but having a clean API is our ultimate goal with UISpec4J. We want
the test classes to be as simple as possible, so that even non-developers
can write functional tests. That's why even though we recently implemented
a findUIComponent method for developers, we still want to provide a simple
Panel.getMyListBox for testers.

Aside from the JDK 5.0 instrumentation API, I cannot see how we can
improve this... We could make the extension mechanism modify UISpec4J's
own JAR, but that seems dangerous. We will probably have to think again in
order to simplify that.

Regards,

Régis.

Hi Regis,

> -----Original Message-----
> From: uispec4j@yahoogroups.com
> [mailto:uispec4j@yahoogroups.com] On Behalf Of Regis Medina
> Sent: Monday, August 08, 2005 5:29 PM
> To: uispec4j@yahoogroups.com
> Subject: Re: [uispec4j] Re: FW: Building UISpec4J
>
> Hi Nascif,
>
> > A patch to fix that would be quite simple:
> > 1) adding a message to the assert in TestCase;
> > 2) adding an assert (with a message!) to the call in TestSuite
>
> It would surely be great to propose this change on a JUnit
> mailing list, so that it gets integrated into their next
> release. Will you do it, or do you want us to do it?

If you could do it it would be great, thanks.

> > I have not used the Extension mechanism, [...]
>
> I agree that having to generate another JAR and updating the
> classpath is quite cumbersome. However, I don't understand
> exactly what you mean to do with the configuration files. Is
> that a means for replacing the generated JAR ?

Yes. You would give up the compile-time checking for some run-time flexibility.
Basically you would add to Panel a generic method called

   UIComponent getUIComponent(String className)

that would check the info from the config file - could be an XML file with the
configuration params for the ExtensionGenerator tool to map className to the
associated class.

The test code would be a little less clean, instead of:

     Panel main = getMainWindow();
     MyListBox scenarioList = main.getMyListBox();

You would have:

     Panel main = getMainWindow();
     MyListBox scenarioList = (MyListBox)main.getUIComponent("MyListBox");

But IMHO it would be an acceptable trade-off. You can actually support both
methods and let the user decide what works best for his development cycle.

> If this is the case, we thought about generating the
> customized Panel class on the fly when it was loaded from the
> JAR, but that would have led us to tricky class loading
> issues (we played with this kind of things for the
> interception mechanism, but it was very difficult to have it
> work in every situation - for instance when running the tests
> from within IntelliJ, which uses its own class loader).

Yeah, I wouldn't go this way either.

> What we could do is switch to JDK 5.0 and use the
> instrumentation API to replace the Panel class at runtime,
> but we cannot use this JDK on our professionnal projet yet...

Same with me, still stuck on 1.4.2.

> Do you have any suggestion ?
See above. :-) Let me know what do you think.

Regards,
   Nascif

Hi Nascif,

> A patch to fix that would be quite simple:
> 1) adding a message to the assert in TestCase;
> 2) adding an assert (with a message!) to the call in TestSuite

It would surely be great to propose this change on a JUnit mailing list,
so that it gets integrated into their next release. Will you do it, or do
you want us to do it?


> I have not used the Extension mechanism, [...]

I agree that having to generate another JAR and updating the classpath is
quite cumbersome. However, I don't understand exactly what you mean to do
with the configuration files. Is that a means for replacing the generated
JAR ?

If this is the case, we thought about generating the customized Panel
class on the fly when it was loaded from the JAR, but that would have led
us to tricky class loading issues (we played with this kind of things for
the interception mechanism, but it was very difficult to have it work in
every situation - for instance when running the tests from within
IntelliJ, which uses its own class loader).
What we could do is switch to JDK 5.0 and use the instrumentation API to
replace the Panel class at runtime, but we cannot use this JDK on our
professionnal projet yet...

Do you have any suggestion ?

Regards,

Régis.

--- In uispec4j@yahoogroups.com, "Regis Medina" <regis.medina@d...> wrote:
> Hi Nascif,
>
> > Problem solved - and I tracked it down to how I defined my testcase
> > constructor [...]
>
> That was tricky, the JUnit message could have been more explicit.
Maybe we
> should tell them about this issue, or suggest a patch? Do you know
were in
> JUnit the assertion error is raised?

Sure. The code that creates the problem is this one, from TestSuite.java:
   static public Test createTest(Class theClass, String name) {
     Constructor constructor;
     try {
       constructor= getTestConstructor(theClass);
     } catch (NoSuchMethodException e) {
       return warning("Class "+theClass.getName()+" has no public
constructor TestCase(String name) or TestCase()");
     }
     Object test;
     try {
       if (constructor.getParameterTypes().length == 0) {
         test= constructor.newInstance(new Object[0]);
         if (test instanceof TestCase)
           ((TestCase) test).setName(name); <<<<
       } else {

Note how it never checks if name is valid (not null).
Then later the assertion that fails is this one from TestCase.java
   protected void runTest() throws Throwable {
     assertNotNull(fName); <<<

A patch to fix that would be quite simple:
1) adding a message to the assert in TestCase;
2) adding an assert (with a message!) to the call in TestSuite

I learned something interesting from this experiment: JUnit creates a
new instance of your testcase class for *each* test method! I guess
this helps ensuring that there is no shared content between tests, but
it was a surprise to me.

> I agree with you that the constructor approach may lead too
frequently to
> this issue, so we will add a setAdapter() as you suggest in release
0.12.
> This setAdapter() could be called from within setUp(), we only need
it on
> a first call to getWindow().

Thanks, I will be looking forward to it.

....
> That's great news! Please do not hesitate to contact us again if you
have
> any suggestion for improving UISpec4J.

Well, I do have another one :-)

I have not used the Extension mechanism, just read about it. Use use
of byte-code extension is very slick, made me think of a customized
application of Aspects. Yet I think it might be a problem concerning
the integration of the tool with the rest of my environment. It will
make it hard to upgrade to new versions of UISpec4J, since it will
force me generate and push to the source code repository a new version
of the jar; it also makes it harder for projects accross the company
to share the library as it one has to have its own modified version
with its own extensions. The alternative is to "recompile" the library
with my own extensions as part of the build, but that adds more
complexity to it. It is feasible, but a little too complex for what
the extension does.

My point is, think about the tool not as a one-time thing, but as part
of a cycle that has to be repeated many times, maintained and shared
across groups.

What about using a configuration file instead? Instead (or in addition
to) using reflection to keep track of "markers" on the class files at
run time, you could just read the former ExtensionGenerator arguments
from a config file, provided as an argument in a system property. This
would be much simpler to track and maintain over the life of a
project, and would allow multiple projects to share the same .jar and
just use their own config files.

Then again, I don't know enough about the Extension mechanism to know
if this proposal even makes sense. What do you think?

Regards,
   Nascif

Hi Nascif,

> Problem solved - and I tracked it down to how I defined my testcase
> constructor [...]

That was tricky, the JUnit message could have been more explicit. Maybe we
should tell them about this issue, or suggest a patch? Do you know were in
JUnit the assertion error is raised?

I agree with you that the constructor approach may lead too frequently to
this issue, so we will add a setAdapter() as you suggest in release 0.12.
This setAdapter() could be called from within setUp(), we only need it on
a first call to getWindow().
Thank you again for taking the time to investigate this and letting us
know about it.


> Other then that, I am quite happy :-) I ported a few testcases from
> Abbot to UISpec and they not only were cleaner (less code) and faster
> (calls to Thread.sleep() removed) but also more powerful - for example
> ListBox supports the selection of multiple indexes, while in Abbot I
> had to "fake" multiple selection using shift-clicks. Everything worked
> just fine!

That's great news! Please do not hesitate to contact us again if you have
any suggestion for improving UISpec4J.

Thanks,

Régis.

Problem solved - and I tracked it down to how I defined my testcase
constructor, which lead to a bad interaction with JUnit. My code was
like this:

   public MyTestCase(String testName) {
     super(new MyUISpecAdapter());
   }

I did this because I was already using the "named" constructor in my
original testcase (it was coded for an older version of JUnit which
required the String arg) and because the "named" ctor in
UISpecTestCase does not set the adapter - and there is no way to set
it later. And I didn't want to use the system property method as I
will have different adapters for different testcases.

The problem with my code is that, if a named constructor (with a
String argument) is available, the JUnit framework will call it
instead of calling the anonymous (no argument) one (see
TestSuite.createTest). And since in the implementation above I do
*not* propagate testName, I ended up triggering an assertion deep
inside JUnit (which IMHO should have a reason string associated with
to make it easier on us users).

So the solution was to change the constructor to:

  public MyTestCase(String testName) {
     super(new MyUISpecAdapter());
     setName(testName);
   }

From this exercise, I would like to suggest a small change in the
UISpecTestCase implementation. Currently there are only two ways to
set the adapter: 1) through a constructor and 2) through a property.

The second one forces you to have one adapter for the entire JUnit
execution, which too limiting if you have a large suite of tests that
exercise different components (unless I am missing something too
obvious, that is).

So I believe in practical terms users will use the constructor-based
approach. But it can lead to problems like the one above (different
constructors leave the object in different states) and it also imposes
an execution flow that may not be a good match for some applications.

In my particular scenario the UI classes are implemented on top of a
threading framework that requires some initialization; to be able to
pass the adapter in the testcase constructor I had to move a lot of
logic around, from the testcase to the adapter.

Instead of the constructor-based initialization, I would add a simple
protected  setter to the UISpecTestCase class to allow the user to set
the adapter later in the constructor, or even in the setUp() method.
This would support more flexible execution flows. In this case the
constructor would become:

  public MyTestCase(String testName) {
     super(testName);
     //... initialization here if necessary
     setAdapter(new MyUISpecAdapter());
   }

or even better:

  public MyTestCase(String testName) {
     super(testName);
   }

  public void setUp() {
     super.setUp();
     //... initialization here if necessary
     setAdapter(new MyUISpecAdapter());
  }

Other then that, I am quite happy :-) I ported a few testcases from
Abbot to UISpec and they not only were cleaner (less code) and faster
(calls to Thread.sleep() removed) but also more powerful - for example
ListBox supports the selection of multiple indexes, while in Abbot I
had to "fake" multiple selection using shift-clicks. Everything worked
just fine!

Many thanks,
   Nascif

--- In uispec4j@yahoogroups.com, "Regis Medina" <regis.medina@d...> wrote:
> Hi Nascif,
>
> Thanks for taking the time to tell us about these issues.
>
>
> > I started playing with UISpec4J - tired of the problems with
Abbot, and
> > curious about the different approach.
>
> What problems did you have with Abbot ? I never used it myself, but I
> thought it was the best tool around.

I have way too many problems with having reliable "reproducable" unit
tests. I run my tests through many different paths - directly from
JUnit, from Emacs calling Ant calling JUnit, from Maven calling JUnit.
And I had tests that would work through one path but not work through
the other. I had to spend a lot of time tweaking properties and delays
to get it to work in maven at all, but I still have problems on occasion.

Don't get me wrong, it is a great tool, and I am glad it is available.
But all that effort made me want to look around for alternatives.

> My first experience has not been very succesful. I converted a Junit
> > testcase from Abbot to UISpec4J, and the mapping from one API to the
> > other was quite simple. But when I run the testcase I get the
following
> > error: [...]
>
> Could you please send me your test files, or any information that
could
> help me investigate the problem ?
> What JDK version are you using ?

I am working on JDK 1.4.1, on Windows XP. The setup is too large to
send, but I will try to isolate it further.

> I cannot see how UISpec4j could influence the behaviour of JUnit.
Maybe an
> exception thrown in the test constructor ? Or during the
initialization of
> the UISpecToolkit ?

It is still a mystery to me. I found some problems in my code and
fixed them - I am now able to call the tests manually and they work fine:

   public static void main(String[] args) {
     UiTest test = new UiTest("test");
     test.setUp();
     test.testEmpty();
     test.testSingleSelection();
   }

But somehow when I try to run using the JUnit TestRunner, I get that
strange error message:

Time: 0
There were 2 failures:
1)
null(com.sas.analytics.irp.client.swing.UiTest)junit.framework.AssertionFailedEr\
ror
2)
null(com.sas.analytics.irp.client.swing.UiTest)junit.framework.AssertionFailedEr\
ror

It is like it failed while running the Reflection step to discover the
testcase methods ! I have no idea of what it could be at this point,
tomorrow I will try to run the whole setup under a debugger.

>
> For the UISpec test cases, our timeouts are maybe too tight. We'll
have to
> work on that obviously.
>
>
> > PS: Regis, your name sounds Brazillian to me. Are you from Brazil
by any
> > chance?
>
> No, I am French (I live near Paris). My name is indeed spanish or
arabian,
> depending on how far you look back in the family history.

Cool, same with me. Grandfather was from Lebanon hence the name.
Regards,
   Nascif

Hi Nascif,

Thanks for taking the time to tell us about these issues.


> I started playing with UISpec4J - tired of the problems with Abbot, and
> curious about the different approach.

What problems did you have with Abbot ? I never used it myself, but I
thought it was the best tool around.


> My first experience has not been very succesful. I converted a Junit
> testcase from Abbot to UISpec4J, and the mapping from one API to the
> other was quite simple. But when I run the testcase I get the following
> error: [...]

Could you please send me your test files, or any information that could
help me investigate the problem ?
What JDK version are you using ?

I cannot see how UISpec4j could influence the behaviour of JUnit. Maybe an
exception thrown in the test constructor ? Or during the initialization of
the UISpecToolkit ?


> My next step was to build UISpec4J locally and run the testcases. [...]
> Everything seems to be fine, with the exception of two test cases that
> failed, and some deprecation warnings (see below). But I still don't
> know how to fix the Junit problem in my own testcases....

The deprecation messages are all caused by our ToolkitDelegate class,
which overrides all the Swing Toolkit methods, even the deprecated ones.
This should not cause any problem.

For the UISpec test cases, our timeouts are maybe too tight. We'll have to
work on that obviously.


> PS: Regis, your name sounds Brazillian to me. Are you from Brazil by any
> chance?

No, I am French (I live near Paris). My name is indeed spanish or arabian,
depending on how far you look back in the family history.

I look forward for hearing from you soon Nascif,

Régis.

Hi all,

I started playing with UISpec4J - tired of the problems with Abbot, and curious
about the different approach.

My first experience has not been very succesful. I converted a Junit testcase
from Abbot to UISpec4J, and the mapping from one API to the other was quite
simple. But when I run the testcase I get the following error:

1)
null(com.sas.analytics.irp.client.swing.UISpec4J_ScenarioComparisonWindowTest)ju\
nit.framework.AssertionFailedError
2)
null(com.sas.analytics.irp.client.swing.UISpec4J_ScenarioComparisonWindowTest)ju\
nit.framework.AssertionFailedError

Note how Junit itself seems to be having problems finding the method name - I
never saw this behavior before.

My next step was to build UISpec4J locally and run the testcases. I had to
change the build.xml file slightly - it still has references to a local drive
(d:/...) which was easily solved by replacing those references with ${basedir}.
The second problem was the use of <get> to retrieve dependencies - since I am
behind a firewall, I had to add a call to <setproxy> to the build.xml file.

After making those changes, I was able to run Ant and Maven. Everything seems to
be fine, with the exception of two test cases that failed, and some deprecation
warnings (see below). But I still don't know how to fix the Junit problem in my
own testcases....

Regards,
   Nascif

PS: Regis, your name sounds Brazillian to me. Are you from Brazil by any chance?
Eu sou de Minas, mas estou trabalhando na Carolina do Norte.

RadioButtonTest
testClickTakesLessTimeThanWithDefaultSwingCalls 0.02
Maximum elapsed time reached: 16 >= 10


WindowInterceptorTest
testTimeoutDuringInterceptionOfANonModalDialog 0.14
expected:<No window was shown> but was:<The shown window is modal, it must be
intercepted with a WindowHandler>



compile:
     [javac] Compiling 81 source files to
C:\home\src\uispec4j-0.11\target\classes
     [javac]
C:\home\src\uispec4j-0.11\src\java\org\uispec4j\interception\ToolkitDelegate.jav\
a:122: warning: getFontList() in java.awt.Toolkit has been deprecated
     [javac]   public String[] getFontList() {
     [javac]                   ^
     [javac]
C:\home\src\uispec4j-0.11\src\java\org\uispec4j\interception\ToolkitDelegate.jav\
a:123: warning: getFontList() in java.awt.Toolkit has been deprecated
     [javac]     return getUnderlyingToolkit().getFontList();
     [javac]                                ^
     [javac]
C:\home\src\uispec4j-0.11\src\java\org\uispec4j\interception\ToolkitDelegate.jav\
a:126: warning: getFontMetrics(java.awt.Font) in java.awt.Toolkit has been
deprecated
     [javac]   public FontMetrics getFontMetrics(Font font) {
     [javac]                      ^
     [javac]
C:\home\src\uispec4j-0.11\src\java\org\uispec4j\interception\ToolkitDelegate.jav\
a:127: warning: getFontMetrics(java.awt.Font) in java.awt.Toolkit has been
deprecated
     [javac]     return getUnderlyingToolkit().getFontMetrics(font);
     [javac]                                ^
     [javac]
C:\home\src\uispec4j-0.11\src\java\org\uispec4j\interception\ToolkitDelegate.jav\
a:206: warning: getFontPeer(java.lang.String,int) in java.awt.Toolkit has been
deprecated
     [javac]   public FontPeer getFontPeer(String name, int style) {
     [javac]                   ^
     [javac] 5 warnings

Hi,

UISpec4J 0.11 is now available. You will find the change log for this
release here:

   http://www.uispec4j.org/changes-report.html

Cheers,

Régis.

Hi,

UISpec4J 0.10 has just been published. The change log for this release
is available here:

     http://www.uispec4j.org/changes-report.html

Cheers,

Régis.

Hi,

UISpec4J 0.9 has just been published. The change log for this release
is available here:

    http://www.uispec4j.org/changes-report.html

Cheers,

Régis.

Hi,

UISpec4J 0.8 has just been published. The change log for this release
is available here:

   http://www.uispec4j.org/changes-report.html

Cheers,

Régis.

Hi,

UISpec4J 0.8 has just been published. The change log for this release
is available here:

   http://www.uispec4j.org/changes-report.html

Cheers,

Régis.

Hi,

In order to keep informed of the project activity, I suggest that
everybody subscribe to the CVS and issues mailing lists. This is done from
the "Mailing lists" page of the http://uispec4j.dev.java.net site (the
link is available on the left-hand bar, in the middle of the "Project
tools" section).

Régis.

Hi,

I agree with Pascal. It seems easier to have a planned time each month.

Sylvain

----- Original Message -----
From: "Pratmarty Pascal" <pascal.pratmarty@...>
To: <uispec4j@yahoogroups.com>
Sent: Saturday, March 12, 2005 11:50 AM
Subject: RE: [uispec4j] Using the java.net issue tracker & planning release
0.8


>
> Hi,
>
> I am interested.
> I suggest that we meet sometime in the first weekend of each month ; does
> this seem honest?
>
> Pascal.
>
> -----Message d'origine-----
> De : Regis Medina [mailto:regis.medina@...]
> Envoyé : jeudi 10 mars 2005 21:42
> À : uispec4j@yahoogroups.com
> Objet : [uispec4j] Using the java.net issue tracker & planning release
> 0.8
>
>
>
> Hi,
>
> Now that we are hosted on java.net, we can use their issue tracking system
> to manage bugs, enhancements and features.
>
> I have already created issues for most of the items we had in the todo.xml
> file. I have also defined some versions and milestones for our project so
> that we can plan release 0.8 and assign items formally between us.
>
> When can we meet to do this "iteration planning meeting"? Who is
> interested?
>
> Régis.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi,
   we can meet each other during the week in the evening or during the
week-end, I have no favorite time.

Seb.

--- In uispec4j@yahoogroups.com, "Regis Medina" <regis.medina@d...>
wrote:
> Hi,
>
> Now that we are hosted on java.net, we can use their issue tracking
system
> to manage bugs, enhancements and features.
>
> I have already created issues for most of the items we had in the
todo.xml
> file. I have also defined some versions and milestones for our
project so
> that we can plan release 0.8 and assign items formally between us.
>
> When can we meet to do this "iteration planning meeting"? Who is
> interested?
>
> Régis.

Hi,

I am interested.
I suggest that we meet sometime in the first weekend of each month ; does
this seem honest?

Pascal.

-----Message d'origine-----
De : Regis Medina [mailto:regis.medina@...]
Envoyé : jeudi 10 mars 2005 21:42
À : uispec4j@yahoogroups.com
Objet : [uispec4j] Using the java.net issue tracker & planning release
0.8



Hi,

Now that we are hosted on java.net, we can use their issue tracking system
to manage bugs, enhancements and features.

I have already created issues for most of the items we had in the todo.xml
file. I have also defined some versions and milestones for our project so
that we can plan release 0.8 and assign items formally between us.

When can we meet to do this "iteration planning meeting"? Who is
interested?

Régis.




Yahoo! Groups Links

Hi,

Now that we are hosted on java.net, we can use their issue tracking system
to manage bugs, enhancements and features.

I have already created issues for most of the items we had in the todo.xml
file. I have also defined some versions and milestones for our project so
that we can plan release 0.8 and assign items formally between us.

When can we meet to do this "iteration planning meeting"? Who is
interested?

Régis.

Hi,

UISpec4J can now be referenced by users from within their Maven
project.xml file:

      <dependency>
        <groupId>uispec4j</groupId>
        <artifactId>uispec4j</artifactId>
        <version>0.7</version>
        <type>jar</type>
        <url>http://www.uispec4j.org</url>
      </dependency>

It will then be downloaded automagically from the Maven repository on the
next build.

Régis.

I was writing this this afternoon:
> I  will keep you informed on any progress made on that.

Well, we have been accepted! We are still in the java.net "incubator", we
will have to request a promotion to a "real JavaDesktop project" status
when we feel that the project is mature enough for a 1.0.

Since no commits were done since we uploaded the source on java.net today,
I propose that we all switch to the java.net CVS hosting starting from
now. Therefore, before doing any modification on UISpec4J, do not forget
to check out a fresh version from java.net.

In order to do this I will certainly need to add you to the project, we
will see in the next few days how this is done.

Régis.

Hi,

We are in the process of hosting UISpec4J in the java.net community:

   https://uispec4j.dev.java.net/

The project is still "pending approval", so we cannot fully switch on java.net
yet. The main problem seems to be that nobody can join the project! I will keep
you informed on any progress made on that.

The sources have already been uploaded to java.net, but since you cannot
retrieve them I would suggest sticking with CVSDude a little longer, we will
upload/update the java.net repository when possible.

A last comment: when committing changes in java.net, I think it is no longer a
good idea to put our names in brackets in the change log. You will see that the
web interface proposed by java.net clearly indicates who performed the
modification.

Régis.

Hi,

UISpec4J 0.7 has just been published. The change log for this release is
available here:

	 http://www.uispec4j.org/changes-report.html

I have requested the upload of this release on the Maven repository.

It's time for planning release 0.8 now !


Cheers,

Régis.

Hi Pascal,

> Currently, this method select the first item matching the value in
> the list.  Don't you think it is strange?
> If you agree, I thought about an alternative: failing in ambiguity
> exception or multi-selecting items, depending on the selection mode.

Having several occurences of a same item in a list seems weird to me..
. What about choosing the exception and let the user try
selectIndices(int[]) for special cases ?

Régis.

Hi Pascal,

> Currently, this method select the first item matching the value in
> the list.  Don't you think it is strange?
> If you agree, I thought about an alternative: failing in ambiguity
> exception or multi-selecting items, depending on the selection mode.

Having several occurences of a same item in a list seems weird to me..
. What about choosing the exception and let the user try
selectIndices(int[]) for special cases ?

Régis.

Hello,

Currently, this method select the first item matching the value in the list.
Don't you think it is strange?
If you agree, I thought about an alternative: failing in ambiguity exception
or multi-selecting items, depending on the selection mode.
Is it too much?

Pascal.

I personally prefer your first solution ; it looks easy to implement and
elegant (indeed the test code may need to be portable between two platforms)

Pascal.

-----Message d'origine-----
De : Regis Medina [mailto:regis.medina@...]
Envoyé : lundi 14 février 2005 22:14
À : uispec4j@yahoogroups.com
Objet : [uispec4j] Managing default colors



Hi,

We have a little problem with AbstractUIComponent.assertForegroundEquals()
and assertBackgroundEquals(): when no color is set by the application
code, the underlying JComponent returns null, causing a
NullPointerException in ColorUtils.assertEquals.

I see two options for addressing this issue (other than just protecting
ColorUtils):

1. Use a new color definition called "default" - after all, do we want the
tests to depend on the color scheme installed on the computer ?

2. Find a way to retrieve the actual default color from the AWT component.

Any idea ?

Régis.




Yahoo! Groups Links

Hi,

We have a little problem with AbstractUIComponent.assertForegroundEquals()
and assertBackgroundEquals(): when no color is set by the application
code, the underlying JComponent returns null, causing a
NullPointerException in ColorUtils.assertEquals.

I see two options for addressing this issue (other than just protecting
ColorUtils):

1. Use a new color definition called "default" - after all, do we want the
tests to depend on the color scheme installed on the computer ?

2. Find a way to retrieve the actual default color from the AWT component.

Any idea ?

Régis.

Hi,

I just removed the previous messages we exchanged on this forum, since
they were all in french. As we open this project to the outside world,
this group will now be in english.

Régis.