The RoyaleUnit Ant task has a "command" parameter where we can pass in the
path of a specific executable. I don't think the Ant task should try to
read a magic environment variable. Instead, we can reference the
environment variable inside the Ant script.
Something like this should probably work:
<royaleunit command="${env.FLASHPLAYER_DEBUGGER}"/>
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Oct 9, 2019 at 11:09 AM Greg Dove <[email protected]> wrote:
> This is partly for general input, but also for Josh specifically in
> relation to RoyaleUnit
>
> Background
> I am continuing to add unit tests, mostly language level stuff.
>
> It is rare, but there can be some things to account for in terms of
> differences caused by the player being used for testing (and also sometimes
> for swf versions).
> This has come up with some XML related stuff recently, where there was a
> one test that failed in the CI build. I discovered this was happening in
> standalone player (probably regular player and air too) only in versions
> between 11.2 and 20.0 - it passes in version 11.1 and versions 21.0+ . I
> only tested this on windows, so it may not be apparent on mac. It wasn't
> failing for me locally because my system player was version 30.
>
> RoyaleUnit testing uses the system file ('.swf') association to launch the
> player. So for some tests it means that they could pass or not depending on
> the version of the standalone player being launched, because bugs were
> fixed in later versions of the player /AVM.
>
> I have my local FLASHPLAYER_DEBUGGER pointing to a 22 version. I know that
> version is used in some of the build configs as well, but it seems that the
> player version for testing on the CI server was something between 11.2 and
> 20 so that firstly seems inconsistent with version 22 used elsewhere.
>
> So two topics really:
>
> 1. General request: Could we agree to standardize the version of the flash
> player we use for RoyaleUnit testing for CI builds? And what version should
> that be. I don't really mind what that is although I think more recent
> versions make sense mainly because I think we should be aiming to emulate
> the most up to date version of the player behavior with various bug fixes.
> However mostly I just would like to be aware of it so I can match it
> locally.
>
> 2. For Josh, a request:
> Could we have RoyaleUnit configurable for the player that should be used
> for testing (with the system player as fallback)?
> I was able to do this quickly locally in WindowsDefaults.java by doing the
> following:
>
> public String getOpenCommand()
> {
> if (System.getenv("FLASHPLAYER_DEBUGGER") != null) {
> return System.getenv("FLASHPLAYER_DEBUGGER");
> }
> return "rundll32";
> }
>
> public String[] getOpenSystemArguments()
> {
> if (System.getenv("FLASHPLAYER_DEBUGGER") != null) {
> return new String[]{""};
> }
> return new String[]{"url.dll,FileProtocolHandler"};
> }
>
> I am not sure if it should be using the same ' FLASHPLAYER_DEBUGGER' env
> var there that we use elsewhere or not... but I was able to use that
> approach to quickly cycle through a lot of different player versions with
> the tests to find the versions that had the issue.
> If it needs to be different it could be something that is specific to
> RoyaleUnit... ROYALEUNIT_SWF_PLAYER or anything really. I don't know if
> this approach works the same on mac... anyhow please consider that
> (generally) as a possible addition for Royaleunit.
>
