I'd say build the tooling under the assumption that the AS is written in a FlexJS JS compatible fashion - i.e. it's basically JS, as you say. If we run into major difficulties that way, we can always create an option into FalconJX that allows us to pass in AS and do a 'simple' pass to create valid JS.
EdB On Wed, Mar 12, 2014 at 3:43 PM, Alex Harui <aha...@adobe.com> wrote: > Well, one of the mustella steps is called RunCode, because we don't have > steps for everything. We will identify common patterns and turn them into > steps to reduce the total amount of AS, but I don't think we can get > everything. There is also a step called AssertMethodValue that calls a > method and checks its value. > > RunCode might do something like: > > <RunCode code="var foo=new Widget(); addChild(foo); foo.currentDate = new > Date()" /> > > Or > > <RunCode code="doSomething()" /> > > Where doSomething() is defined in the fx:Script block. > > There's a good chance that just about all of the AS is essentially just > JS. We can say not to define new classes or use "for each" and other non > JS stuff, and even fully qualify classes if that makes things easier. > > -Alex > > On 3/12/14 6:44 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > > >Can you give an example of what AS might be in the test descriptor file? > > > >EdB > > > > > > > > > >On Wed, Mar 12, 2014 at 2:37 PM, Alex Harui <aha...@adobe.com> wrote: > > > >> > >> > >> On 3/12/14 12:34 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >> > >> >> > >> >> The MXML test script should be valid XML, so it should be easily > >>parsed > >> >>by > >> >> Java code. We have to figure out what to do with any fx:Script > >>block, > >> >>but > >> >> otherwise, maybe each MXML tag just runs a Java class? For MXML > >>event > >> >> handling code in AS, maybe that just gets passed to JS eval()? Or > >> >> cross-compiled first by FalconJX? I guess this approach would make > >> >>bitmap > >> >> compares possible? If so, maybe this approach would be less work. > >> >> > >> > > >> >If I understand correctly, Mustella has two inputs: the MXML/AS file to > >> >test and an MXML file that defines what to test. In the Marmotinni > >> >approach, the test file would indeed be cross compiled by FalconJX, > >>giving > >> >us a fully fletched release HTML/JS application to test. To perform > >>this > >> >testing, in comes Selenium, which can be driven from a Java application > >> >(the actual Marmotinni). This application reads the MXML file defining > >>the > >> >tests, parses them to Selenium commands, captures the Selenium results > >>and > >> >reports them. If there is any mixin' to do, or if the HTML/JS > >>application > >> >needs to be modified/enhanced/added to in any way, FalconJX can take > >>care > >> >of this. There are already code paths and a command line switch in > >> >FalconJX > >> >(the Publisher, to be specific) that handle special cases when a build > >>is > >> >part of a Marmotinni run. > >> That's pretty much correct. The only wrinkle is that the MXML file that > >> defines what to test may also have some AS in it. That might require a > >> separate compilation by FalconJX. Can Selenium inject JS to execute > >> somehow? > >> > >> I think I've changed my mind and will start down this road instead. > >> Thanks for the valuable input. > >> > >> -Alex > >> > >> > > > > > >-- > >Ix Multimedia Software > > > >Jan Luykenstraat 27 > >3521 VB Utrecht > > > >T. 06-51952295 > >I. www.ixsoftware.nl > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
