The goal of Mustella was to write tests in a declarative language, in this case, MXML. That way, the test could be "interpreted" instead of just run, so the test harness could have control over timing and some other things that are really tricky in Flash like script timeouts and needing to allow the player to render.
MXML would theoretically make tests shorter to write for the same reasons folks like declarative languages in general. And reduce errors, possibly allow automated test generation, etc. So maybe the first question is: Do we want to write tests that run on both SWF and JS? I think we should since that reduces time to create tests for both platforms and potentially add some third platform in the future. But if you are only interested in one platform, then sure, go ahead and leverage what is popular and available for that one platform. And yes, it could be easier to take what is available for JS and back port it to SWF. I was just trying to leverage what we (Apache and not Adobe) have in our repos. There are a lot of existing tests for the regular Flex SDK that could potentially be used as is or with small modifications. Is Mustella/Marmotinni buggy, poorly documented, in need of improvement? Yes. It was never production-grade but was used to help us ship Flex. I just wanted to make sure you are aware it exists. -Alex On 1/8/17, 11:52 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Hi Alex, > >Well I have to admit that Mustella is a thing I always tried avoiding as >I never really managed to wrap my head around it. Just had a look at the >FlexJS version and it seems to be a copy of (parts) of Mustella from the >Flex SDK. At least from a few minutes of looking at the code I couldn’t >really understand the basic concepts of the tests. > >I can see some part which seems to be FlexJS code as well as some Java >code in a package “marmotinni” which is probably somehow related to the >neighbor directory “marmotinni”. I couldn’t really see any documentation >or code-comments that would explain things. And having a look at the >commit history for both directories, It’s only you contributing to this >at all (except the initial commit of the marmotinni directory, which was >from eric). Also having a look at the history of the Flex SDK, there >seems to be a similar picture. It’s a very elite group of people doing >commits there and usually related to tweaking things instead of really >writing tests. > >If I would have to decide, I would definitely go the Junit + Selenium >path the way I set it up (But doesn’t have to be that way as long as we >stick to a more standard way that’s integratable into the Maven build). >The main reason for this is that it’s the way - I wouldn’t say the rest >of the world, but the greater part of it – does things. It uses well >established mechanisms, which people are probably more familiar with and >definitely will be able to get more assistance, blogs, how-tos, a.s.o. >for. I know that setting up the initial project is challenging, but I >already did that for us. Now all we would need to do in order to add new >tests, is write a simple Junit test and eventually add a dependency to a >new example project. > >Another thing I don’t quite like with Mustella, the way I have seen it >with the old SDK, is that it doesn’t seem to be deterministic. If I need >to loop tests several times in order for them to run, I can’t trust the >tool as a proper test tool. > >I would definitely vote for going down the more standard path than the >proprietary Adobe path for testing. Considering that we don’t really have >more than a proof of concept of a test-suite, I don’t think we would be >throwing away much. > >Chris > > >Am 09.01.17, 06:37 schrieb "Alex Harui" <aha...@adobe.com>: > > Did you look into how Mustella/Marmotinni works? That is also an >attempt > to use Selenium. > > -Alex > > On 1/8/17, 11:23 AM, "Christofer Dutz" <christofer.d...@c-ware.de> >wrote: > > >Hi, > > > >After noticing that some examples seem to compile fine, but don’t > >actually work, I decided to invest a day in building integration >tests to > >test the examples in a browser (currently Firefox). > >As this requires the “Geckodriver” to be installed, I made the tests >auto > >activate themselves as soon as the “webdriver.gecko.driver“ property >is > >set to the path of the geckodriver executable. > > > >What happens is: > > > >- The tests are compiled > > > >- A Tomcat8 is setup and started > > > >- the HelloWorld example is deployed > > > >- The Selenium JUnit Tests are run > > > >- The tomcat is shutdown > > > >Please have a look at this, if you think this is a valid path, then I > >would start writing some test-cases that basically test some of our > >examples. > > > >Get geckodriver from here: >https://github.com/mozilla/geckodriver/releases > >I needed to update my Firefox to the latest version in order for the > >tests to run. > > > >Chris > > >
