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

[Pavel Tisnovsky]

Jiri Vanek wrote:
> 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.

Hi Jiri,

these changes look good - approved.

Thanks,
Pavel

> 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
>>>
>>
>