Yeah, I think it would make a lot of sense to update our build scripts to use this environment variable when launching RoyaleUnit tests. I'm pretty sure that it is already set on the CI server for Mustella tests, so we should have the build consistently use the same version for everything.
As a bonus, setting the default program for .swf files won't be necessary anymore. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Wed, Oct 9, 2019 at 11:46 AM Greg Dove <greg.d...@gmail.com> wrote: > 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 <joshtynj...@bowlerhat.dev> > 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 <greg.d...@gmail.com> 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. > > > > > >
