Thanks Josh, that definitely sounds like a better option. I will give that a try for that side of things locally. Maybe we can also use this on the CI server to specify the version that is used?
On Thu, Oct 10, 2019 at 7:30 AM Josh Tynjala <[email protected]> wrote: > 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. > > >
