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

Fri Mar 16 01:31:52 PDT 2012

Hi Pavel

All your issues have been fixed in this version. of patch, except few which we have been talking in office, and except remote testing which is definitely for different patch and  I consider it as suspended until the need arise.
Just to summary our talk:
Browsers will be handled by annotations (thanx for forcing me to investigate this way , are working great! ;)
XslowX will remain name-convention till now
the proof of concept of appelts testing is still included, and I'm forking 100% on anotated version (As investigated on wed+thu). It will change mostly transparently to current version (to keep it simple for final tests writing)
Still o luck with awt-robot, possibility of new framework (extending current one)  to lunching complex applications (including robot, and remote serer) considered.

Ok for head now?

Thanx for review!
J.

2012-03-16  Jiri Vanek <jvanek at redhat.com>
     * tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java: as javaws have now integrated splash, I have changed this test to lunch javaws -Xclearcache with -headless to skip this logo (although it is not fatal fr testrun itself)
     * tests/jnlp_tests/simple/AppletTest/resources/appletAutoTests.html: this html file is lunched during tests run in browser and stdout of lunched applet is examined. Is lunched with slow resources to test spalshscreen
     * tests/jnlp_tests/simple/AppletTest/resources/appletViewTest.html: this test html file is dedicated to manual lunch and let user to look how the applet (with slow loading) is loaded and how looks splashscreen in small mode and in large mode
     * tests/jnlp_tests/simple/AppletTest/testcases/AppletTestTests.java: test is enriched for lunching the html file with applet in browser and is examining output of this file. Browser must be always terminated as there is no way hoe to close from inside
     * tests/jnlp_tests/simple/simpletest1/resources/netxPlugin.png : image to let user observe that user-defined splashscreen is still working even when internal splashscreen is enabled
     * tests/jnlp_tests/simple/simpletest1/resources/simpletestCustomSplash.jnlp: this and all jnlp files below are just for manual lunching and for watching various lunches of splash screen - slow loading of resources and with custom splash
     * tests/jnlp_tests/simple/simpletest1/resources/simpletestMegaSlow.jnlp:  slow loading of  resource and (XslowX)jnlp also
     * tests/jnlp_tests/simple/simpletest1/resources/simpletestSlow.jnlp: slow loading of resource
     * tests/jnlp_tests/simple/simpletest1/resources/simpletestSlowBrokenCustomSplash.jnlp: slow loading of resource with broken user's splash (our internal will be used)
     * tests/jnlp_tests/simple/simpletest1/resources/simpletestSlowSlowCustomSplash.jnlp: slow loading of custom splash screen and resource
     * tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java: Main server launcher was modified to support lunching of browser, stdout listteners and for slowing download of resources to provide time for watching splash screen
      (main) was rewritten to provide free port OR run server in-D specified directory on custom or default port - very useful for debuging reproducers
      (getIndependentInstance) can now run also on specified port and (or) directory
      (USED_BROWSER_COMMAND) new constant handling value of -D property to set browser = "used.browser.command";
      (getBrowserLocation) new method  to provide specified (by used.browser.command -D property) or default browser location (firefox)
      (ensureServer) test is testing weather XslowXmodifier is working
      (executeBrowser) set of overloaded functions to lunch browser
      (TinyHttpdImpl) was enriched for XslowX modifier. When resource starts with this, is returned slowly - splited to 10 parts with 1s delay betwen sending each of them. Although it is throwing BrokenPipe exception, is working fine.
      (splitArray) new function to split array of byte to n arrays of bytes, which when concated do the same array
      (splitArrayTestN) set of tests for splitArray
      (ContentReader) now can also have lsteners for catching outputs n runtime.
     * tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ContentReaderListener.java: Listener for catching chars and lines form processes outputs
     * tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ResourcesTest.java: added (testListeners) to test listeners behaviour
On 03/12/2012 03:40 PM, Jiri Vanek wrote:
> 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
>>>>
snip
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: splasScreenTests4.diff
Type: text/x-patch
Size: 42235 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120316/e8f0427b/splasScreenTests4.diff 