incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger>
Subject Re: [DECISION] Unit Testing and Mocking Frameworks (was: [RT] Recommendation Unit-Test System?)
Date Mon, 13 Feb 2012 08:31:34 GMT

But we still have a practical problem: Even when FlexUnit is given to 
the Flex SDK: Mockolate and
its dependencies are not. Those would be the first "external" libraries 
that Apache Flex would rely
on. Flex can not be built without them.

In my mind: Open source is open source: That means Apache can deploy 
other projects too, if those
projects are under a compatible license: just publish the .swc with the 
rest of the code. Right?

Now I wonder: For deployment would a Category B license be enough? MIT? 
Or is it necessary to be
of Apache compatible (BSD).


On 13/02/2012 09:04, Omar Gonzalez wrote:
> After the discussion we had around unit testing and mocking frameworks we
> had two very generous offers from Michael Labriola (FlexUnit) and Drew
> Bourne (Mockolate/hamcrest-as3).
> Michael is awaiting feedback from a mentor (Bertrand was on the thread) on
> what the next steps would be to make a donation of the source code for
> FlexUnit.
> Drew offered to help with any issues we may encounter with Mockolate or
> hamcrest-as3 that would prevent us from using them as the libraries we use
> to test the Flex SDK.
> In light of these two generous offers from the authors of these libraries I
> think that FlexUnit, Mockolate, and hamcrest-as3 should be the libraries
> that we adopt as the testing libraries for the Flex SDK.
> My reasoning:
> - Multiple testing frameworks would be messy.
> - Managing build files with multiple testing frameworks could get messy.
> - Managing reports for unit tests from multiple testing frameworks could
> get messy.
> - Both authors for the frameworks have offered help or a donation to the
> project, I think we should take it! :)
> - FlexUnit is supported in Eclipse editors and IntelliJ
> - Mockolate can also verify using reflection, eliminating the concern of
> magic string usage
> Can we come to a consensus on these 3 libraries? This will allow people to
> comfortably get working on writing unit tests for the SDK. Nobody wants to
> refactor code unnecessarily, so I think we should decide on the libraries.
> What do you guys think?
> -omar

View raw message