On 3/11/14 11:01 PM, "Sean Thayne" <s...@skyseek.com> wrote:
>If you ran the JS tests inside of an air app, you could generate bitmaps >for comparison.. But, that wouldn't really work to test different >browsers, >which is another thing FlexJS will probably need. To test everything in >all >major browsers. True. And I think that's why Selenium is probably part of the equation. More details: A simple Mustella run generally consists of one MXML-based test "script" that lists an MXML-based application as the "testSWF". The MXML application has no class dependencies on Mustella classes or the MXML test script. The Mustella classes and test script are linked into the SWF as [Mixin]s and thus are initialized at startup where they work together to fake events, change properties and test the value of properties. For checkintests, the Mustella classes are linked in via a -config.xml file. When you use mini_run, Java code parses the test scripts, figures out which test scripts require which application MXML files and aggregates all scripts that use the same application together in order to save time on the number of times we launch the player. Because there are no class dependencies between the application MXML and the test script, we have the option of cross-compiling the application MXML, and not cross-compiling the test script and instead parsing the test script's MXML (and AS) and converting it to Java somehow. For dealing with the AS, we could run the snippets through FalconJX to get the resulting JS, or maybe place more restrictions on the kinds of AS you might write in an MXML test script. If you look at existing test scripts, you'll see way more AS than there should be. Most of the AS code in fx:Script blocks should be represented by additional test steps. The remaining AS might really just be the same as the JS. Anyway, still musingŠ -Alex
