Applet's in browser, slow loading, remote and (in some bright future) graphical testing and some minor improvements (was Re: Icedtea-web splashscreen implementation)

[Jiri Vanek]

On 03/12/2012 02:07 PM, Pavel Tisnovsky wrote:
> Jiri Vanek wrote:
>> On 03/12/2012 12:11 PM, Pavel Tisnovsky wrote:
>>> Hi Jiri,
>>>
>>> I'd like to comment the last patch with new test framework functionality:
>>>
>>> 1) the idea of adding some delay to see/test splashscreen is great,
>>> but is not
>>>      it better to add some annotation to such tests instead of using
>>> "magic" test name?
>>>      Similar functionality is used in JTreg tests (not "true"
>>> annotations, but similar approach).
>>>      I'm sure we'll need to add more per-test parameters in the future.
>>
>> hmhm interesting idea, but I need to specify this inside JNLP file or
>> inside applet tag in html file. And I wanted to lunch it outside the
>> engine.... Have you any clue how to do this with annotation?
>
> Yes, you can AFAIK use "property" tag in JNLP file. It contains "name"
> and "value" and this pair should be available through System.getProperty()
> (there probably exist tests which check this functionality :-)
>
> So we could prepare a list of some properties used by the test machinery.

ugh ugh... Can you say little bit more about this idea? And applets? And usage inside/outside/itself engine?
>
>>>
>>> 2) some notes to the patch:
>>>
>> Indentation - Damn this:-/ I was doublechecking this across all the
>> files :-/
>>> tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ResourcesTest.java:
>>> - seems there's a bad indentation for the last 11 lines
>> ..not found...??
>>> tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
>>> - bad indentation in a method getIndependentInstance()
>> fixed
>>> - -//- for executeJavawsHeadless
>> fixed
>>> - -//- executeJavaws, executeBrowser
>> fixed
>>
>>
>> And concept of  executeBrowser and listeners at all?
>> Is it worthy to continue this way? What about "firefox" issue?
>> And posted testcases? Especially the applet in browser one? And change
>> in main method? And issue with link?
>
> Well it's focused to test Firefox only at this moment, but I think
> that we can start with your solution and then update it to support Chrome
> etc. etc. (it should be easy IMHO).

True. I will add function which will return iterator for all possible browsers. So each test will be possible to run in all set browsers.

>
>>
>> The issue with link and with browser is quit fundamental and I'm not
>> sure how to continue with it. There is -Dvariable for setting up bowser,
>> but it do not solve anything at all :( And the link issue is even more
>> tricky with various (means supported x the testing one)  browsers. Or
>> should ve be happy with firefox? Or should this test to be
>> multi-browsers? (== during each run, each html test wil be lunched in
>> all possibel browser [I do not believe this is worthy, but recent
>> regression on chromium shows differently])
>
> But why not? After all the number of browsers supported is still quite small (er Opera er ;-)
As told above... Will be done. So we have Firefox and Chromium supported? Waht about chrome? opera? safari?

Still I don't know how to handle link for firefox, and have absolutly no clue about other browser.... This is becoming quite funny :)
>
>>
>> Although I have posted this in-browser tests as proof-of concept, there
>> is already need for applets tests so I'm for to push it in, because
>> abstraction, as it is written, is quite enough and improvements can be
>> done in "runtime".
>
> I agree.
Is there something more then javadoc, browser iterator, and tuned byte[] split  You want me to do before next review round?
>
>>
>>> - -//- splitArray (it needs JavaDoc
>> definitely. Sorry for forgot it.
>> too, contains double ";;" on one line etc.)
>> damn. YY - fixed
>>>     I think it could be simplified to use one loop only and two index
>>> variables
>>>     (we can talk about this personally)
>> Can it? Make your shot! O:) Btw  - I have *one* loop, tehn second O:)
>> for copyying of aray (As I'm not friend of copyarray method :( ) and
>> *one* index, but yes, the header of method is not nice. But it was still
>> fighting with me:-/ Make your shot!
> will send :-)
>>
>>> - I'm probably wrong but is seems that all applet/jnlp tests are using
>>> only "localhost" network interface.
>>> If it is true I'm afraid we miss some iptables-related or IPv6 related
>>> issues.
>> Hmhm.. very interesting topic (== you are not wrong), but it should be
>> raised when the test-engine was done (bud good that wasnt O!o) )
>> On the other side, the  testing framework on client itself can handle
>> this. The problem is to have some server running. To have it integrated
>> inside current makefile can be quit tricky, and I'm strongly against.
>> Currently I'm against to add this feature at all, because there is no
>> known issue with this and local host seem to be enough.
>> In case this issue will rise with higher priority, then my suggestion
>> will be:
>> 1) to have  some remote server running and working - absolutely out of
>> icetea-web makefile's control
>> 2) set eg  --with-remote-server=my.server.org:xyz/something  the remote
>> server configurated for coopeartion
>> 3) makefile will sed urls in (selected?) jnlps/htmls and, and will pass
>> this url to testengine so it will know where to requests jnlps and htmls
>> 4) makefile will copy (selected?) resources to this remote server,
>> 5) the tests run will run as usual, because stdout/err/gui examination
>> will behave in same way as in localhost.
>>
>> Acctually I do not see some big issue with this approach at all, and in
>> case it will become handy it can be implemented.
>>   The only change in current implementation will be passing list of tests
>> which should run remotly.  In testengine run I can imageine some
>> extension to executeJavaws(..) method Eg executeRemoteJavaws(...) -
>> there is enough  abstraction  level to handle this properly. During
>> compilation of reproducers and copying of resources it will need some
>> list (or directory) to specify remote ones .
>>
>> But really - until there is some real need for this reproducers, I would
>> rather stand without this.
>>>
>>> Cheers,
>>> Pavel
>>>
>>> (Hint: Eclipse Ctrl+F)
>> Yap NB have the same. But the issue is between computer and keyboard (as
>> always with me and indentation)
>>>
>>> Jiri Vanek wrote:
>> Snip
>>>
>>> *Testing*
>>> _splash tests_
>>> I was "facing really huge problem" When I wanted to see spalshscreen
>>> inside browser - it was always to quickly lost :) So Ihave added magic
>>> prefix XslowX to be rocgnized by internal server. When some resource
>>> starts with this prefix, its without-prefix-version is returned as
>>> resource. The difference is that its downloading is delayed to 10s
>>> (10%per seccond). It is done by spliting this resource's byte[] to 10
>>> peaces. This throws BrokenPipe Exception, but is working fine.
>>> Minor improvement inside ServerAcces.main() is tighter integration with
>>> testing framework - It can now be lunched instead of eg python
>>> smallHTTPserver and working directory is set in same way as during tests
>>> by -D property (so it can be lunched with same environment settings as
>>> in-ide tests)
>>> Second problem I was facing was automated testing of applets in firefox.
>>> The integration of "lunch html with browser, examine stdout/stderr,kill
>>> firefox" required just small changes and is working really well.
>>> But there is one big TODO - to configure (in make?) browser so it works
>>> with JUST BUILT iced-tea-web-plugin. Currently it expects to have
>>> firefox well configured (= to link
>>> /usr/lib/mozzila/libs/plugins/icedteaweb-plugin.so (or wherever firefox
>>> have plugins) with the one in --prefix path). But it is not the best
>>> way. To future I'm thinking about customised "embeded" firefox or to
>>> some  link-plugin makefile target (run under root) which fill create
>>> this link (currently iced tea-web's install do not create this link, it
>>> is done in RPM post), or to have some local firefox which can be
>>> linkable without root and provide --with_browser.... - *any ideas
>>> welcomed* !
>>> And one small to do - in some future integrate awt-robot (+stdin/out)
>>> listeners
>>> _new tests_
>>> One new automated test is added to demonstrate the powers of testing of
>>> applets inside browser
>>> Bunch of new test which are using XslowX to allow everybody to see
>>> various cases of spalshscreens. Those tests are not automated and are
>>> testing custom splash, broken custom splash, my splashes... broken
>>> stuff..both for applets and javaws
>>
>> ...snip...
>>
>> J.
>>
>>
>