Also note that when I Remote Desktop into apacheroyaleci, I have seen a 
"Firefox closed unexpectedly when starting" dialog a couple of times.  I've not 
seen that before, so might be related to your changes.

-Alex

On 5/23/19, 7:47 PM, "Alex Harui" <[email protected]> wrote:

    First off, this sounds like a great new capability for Royale, so thanks 
for working on it.
    
    Regarding JS test issues, did you rule out using Selenium?  I haven't had 
problems with it on Mac or Win for Mustella.
    
    HTH,
    -Alex
    
    On 5/23/19, 4:20 PM, "Josh Tynjala" <[email protected]> wrote:
    
        Unfortunately, I had to disable the JS tests automatically running on 
the royale-asjs main build because they intermittently fail on macOS. It seems 
that the port that the WebSocket server uses isn't released until some time 
after the <royaleunit> task completes. So, after one Royale library is tested, 
the next might fail. I haven't figured out what's causing it yet. Additionally, 
this issue does not affect Windows.
        
        The JS tests are still available, if you'd like to run them manually. 
The following commands will run tests for CoreJS:
        
        cd frameworks/js/projects/CoreJS
        ant test
        
        We currently have JS tests for CoreJS, BasicJS, and RoyaleUnitJS.
        
        - Josh
        
        On 2019/05/23 19:18:21, Josh Tynjala <[email protected]> wrote: 
        > Hey Royale team,
        > 
        > Over the last several days, I've been working on RoyaleUnit again, 
and I wanted to share a bit about what I've completed this week.
        > 
        > ## New <royaleunit> Ant task
        > 
        > Until now, we've been using the <flexunit> Ant task to run RoyaleUnit 
tests on our SWF output in the Ant builds. The RoyaleUnit library is similar to 
FlexUnit, but it's a completely new implementation that works on both SWF and 
JS. When I first created RoyaleUnit, I could only get SWF output successfully 
communicating with the <flexunit> Ant task. JS tests could be run manually, but 
they could not be automated in Ant yet, for technical reasons.
        > 
        > On the SWF side, FlexUnit uses XMLSocket to communicate with the 
<flexunit> Ant task. That was easy enough to port over to RoyaleUnit. However, 
JS in the browser doesn't have a simple socket implementation that would allow 
it to speak the same protocol. The closest thing is WebSocket, but the 
<flexunit> Ant task doesn't know how to talk to WebSockets. So, I created a new 
<royaleunit> Ant task that can still speak XMLSocket with SWF, but also 
supports WebSocket for JS.
        > 
        > Previously, you could specify "flash" or "air" for the player value 
in the Ant task:
        > 
        > <royaleunit player="flash" />
        > <royaleunit player="air" />
        > 
        > I added a new one, "html", that tells the Ant task to use WebSockets.
        > 
        > <royaleunit player="html" />
        > 
        > Then, you can use the swf property to specify the HTML file to launch:
        > 
        > <royaleunit player="html" swf="bin/js-debug/index.html" />
        > 
        > (It was already called "swf" in <flexunit>, but maybe we should 
rename it or provide an alias)
        > 
        > By default, it should use your default web browser. However, if you'd 
prefer a different browser, you can use the command property:
        > 
        > <royaleunit player="html" swf="bin/js-debug/index.html" 
command="c:/Program Files/Mozilla Firefox/firefox.exe" />
        > 
        > ## Ant builds run JS tests
        > 
        > After I got the <royaleunit> Ant task work, I updated our royale-asjs 
Ant builds to run both SWF and JS tests. This was interesting because it needs 
to launch a web browser, and there are some gotchas that I discovered.
        > 
        > In particular, Internet Explorer always requires the user to manually 
click a button to allow JavaScript content to run in a local HTML file. 
Likewise, the first time a local file is launched in Safari, it asks to confirm 
if you want to open it or not. When you try to open the file again later, 
Safari opens it without asking, but that first time isn't ideal.
        > 
        > With the two default browsers not really good candidates, I decided 
to try Chrome and Firefox. I found that both will run scripts without a prompt, 
but they aren't necessarily installed on everyone's systems. So, first it looks 
for Chrome (which is the most popular browser these days), and then it falls 
back to Firefox. If it can't find either one, the build fails with an error.
        > 
        > In the case where a browser cannot be found automatically, there is 
the option to specify a royaleunit.browser property when running the Ant build 
script. You can either add it to your *env.properties* file in the root of 
royale-asjs, or you can specify it on the command line like this:
        > 
        > ant -Droyaleunit.browser=path/to/browser.exe
        > 
        > (On macOS, I think that you need to point to the native executable 
instead of the .app file, like /Applications/Firefox.app/Contents/MacOS/firefox)
        > 
        > When <royaleunit> finishes running JS tests in the browser, it will 
automatically close the browser — except when that browser was already open 
before you started running the tests. In that case, it will simply open a new 
tab, which will remain open after the tests complete. So, it won't make you 
lose all of your existing tabs or anything. However, it may be annoying to have 
a bunch of extra tabs that you need to manually close every time that you run 
the build script. In that case, just like I explained above, you can use the 
royaleunit.browser property in env.properties or via the command line to tell 
the build to run JS tests in a different browser that you prefer. As I 
mentioned, if that browser isn't already open, the build script will exit the 
browser automatically after running tests.
        > 
        > I confirmed that apacheroyaleci on Azure has Firefox installed, and 
at least one build has completed successfully on this server.
        > 
        > Please let me know if this has disrupted anything. However, I think 
that I covered the edge cases pretty well.
        > 
        > - Josh
        > 
        
    
    

Reply via email to