Mailing List Archive

Hi Tomoko,

Many of the things that popped up recently could be done with regular tests
- only organized
a little bit differently. For example, I envision adding a parameter
"--test-mode" which would cause Luke to dump some
diagnostic information about the stuff it "sees" in SPIs, etc. - this
information would then be confronted with an existing
expectation. It doesn't even need to start in full GUI mode (which is
always a problem with headless CIs).

Some of these tests will have to be written for the "module mode" as proper
integration tests. It's all coming at us anyway.

More to your question - no, I never found a GUI test framework that would
require way more maintenance than
the application itself...

Dawid

On Fri, Nov 26, 2021 at 1:04 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Hi,
> if perhaps there is anyone with experience in Java GUI app tests,
> could you share your knowledge/expertise? It would be helpful if we
> have some basic components rendering or smoke tests for Luke GUI, that
> can be integrated into the nightly check job. The application itself
> would not be so frequently changed but having some sanity checks is
> always good.
>
> While there seem to be a few testing frameworks for Java GUI, I cannot
> say I have sufficient experience to select a better tool for us (Luke
> is the only desktop application I've ever written).
> Your advice is helpful.
>
> Thanks,
> Tomoko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Hi Dawid,

I agree with plain tests without the GUI are the best. Regarding Luke,
I think it'd be helpful if we check values that are obtained from the
outside module/data and used to populate the Swing components (lists,
dropdowns, etc.) - this might be the simplest form of the integration
test.

Tomoko

2021?11?26?(?) 22:38 Dawid Weiss <dawid.weiss@gmail.com>:
>
>
> Hi Tomoko,
>
> Many of the things that popped up recently could be done with regular tests - only organized
> a little bit differently. For example, I envision adding a parameter "--test-mode" which would cause Luke to dump some
> diagnostic information about the stuff it "sees" in SPIs, etc. - this information would then be confronted with an existing
> expectation. It doesn't even need to start in full GUI mode (which is always a problem with headless CIs).
>
> Some of these tests will have to be written for the "module mode" as proper integration tests. It's all coming at us anyway.
>
> More to your question - no, I never found a GUI test framework that would require way more maintenance than
> the application itself...
>
> Dawid
>
> On Fri, Nov 26, 2021 at 1:04 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com> wrote:
>>
>> Hi,
>> if perhaps there is anyone with experience in Java GUI app tests,
>> could you share your knowledge/expertise? It would be helpful if we
>> have some basic components rendering or smoke tests for Luke GUI, that
>> can be integrated into the nightly check job. The application itself
>> would not be so frequently changed but having some sanity checks is
>> always good.
>>
>> While there seem to be a few testing frameworks for Java GUI, I cannot
>> say I have sufficient experience to select a better tool for us (Luke
>> is the only desktop application I've ever written).
>> Your advice is helpful.
>>
>> Thanks,
>> Tomoko
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Yes - that's exactly what I was thinking of doing. My suggestion was to add
an internal parameter to Luke because then it can be run as an application
(an isolated jvm forked from within an integration test) - something that
it hard to ensure if you use unit tests.

On Fri, Nov 26, 2021 at 5:01 PM Tomoko Uchida <tomoko.uchida.1111@gmail.com>
wrote:

> Hi Dawid,
>
> I agree with plain tests without the GUI are the best. Regarding Luke,
> I think it'd be helpful if we check values that are obtained from the
> outside module/data and used to populate the Swing components (lists,
> dropdowns, etc.) - this might be the simplest form of the integration
> test.
>
> Tomoko
>
> 2021?11?26?(?) 22:38 Dawid Weiss <dawid.weiss@gmail.com>:
> >
> >
> > Hi Tomoko,
> >
> > Many of the things that popped up recently could be done with regular
> tests - only organized
> > a little bit differently. For example, I envision adding a parameter
> "--test-mode" which would cause Luke to dump some
> > diagnostic information about the stuff it "sees" in SPIs, etc. - this
> information would then be confronted with an existing
> > expectation. It doesn't even need to start in full GUI mode (which is
> always a problem with headless CIs).
> >
> > Some of these tests will have to be written for the "module mode" as
> proper integration tests. It's all coming at us anyway.
> >
> > More to your question - no, I never found a GUI test framework that
> would require way more maintenance than
> > the application itself...
> >
> > Dawid
> >
> > On Fri, Nov 26, 2021 at 1:04 PM Tomoko Uchida <
> tomoko.uchida.1111@gmail.com> wrote:
> >>
> >> Hi,
> >> if perhaps there is anyone with experience in Java GUI app tests,
> >> could you share your knowledge/expertise? It would be helpful if we
> >> have some basic components rendering or smoke tests for Luke GUI, that
> >> can be integrated into the nightly check job. The application itself
> >> would not be so frequently changed but having some sanity checks is
> >> always good.
> >>
> >> While there seem to be a few testing frameworks for Java GUI, I cannot
> >> say I have sufficient experience to select a better tool for us (Luke
> >> is the only desktop application I've ever written).
> >> Your advice is helpful.
> >>
> >> Thanks,
> >> Tomoko
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>