asunit-users

[Asunit-users] FlexUnit4 features and AsUnit direction

[Luke B. <lb...@pa...>]

I did some digging this weekend into FlexUnit 4 sources, implementations and
metadata / annotations in MXMLC.

One major problem I have with metadata tags is that they can only be
discovered at runtime for public members. I imagine there are hooks in the
compiler that make [Bindable] and [Embed] work even for
private/protected/namespaced members, but getting into runtime, custom tags
means we have access only to public members that are visible to
describeType.

This is a little annoying to me, because I value having private / protected
features for set up and tear down, as well as test helpers with custom
domain-specific assertions. It feels awkward to expose these methods as
public everywhere.

I'm also annoyed with metadata in that we don't have any reliable
information about the 'order of declaration' which leads to ugly duplication
like [Before(order=1)], [Before(order=2)], etc.

Then there are of course the issues Robert uncovered around supporting
metadata in Authoring CS3, which pretty much means that today - MXMLC is the
only compiler for which these tags have value.

The worst news is that the FlexUnit 3 implementation (excluding the
printers) had pretty limited Flex framework dependencies, all of which would
have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
integrated the AsyncToken garbage along with Flex collections and Logging.
Fluint (which is now also bundled) has extensive framework dependencies that
are unlikely to be extricated without a major overhaul...

My conclusions at this point are as follows:

FlexUnit is now appropriately named and works only with projects that don't
mind executing tests within a Flex application SWF.

I'm not sure I really understand the true value of annotations when compared
to inheritance... We could certainly gain many of the benefits (multiple
setup/teardown, class-level setup/teardown, and custom assertions using
inheritance and minor modifications to our existing code.

I perceive the real value of the latest release of FlexUnit to actually be
the following:

1) Fluint seems to do a great job of describing and handling asynchronous
event sequences

2) Hamcrest seems to be helpful for mocking and stubbing features

3) Generators and test output integrated into Eclipse

It might be a worthwhile endeavor for us to do the following:

1) Improve how we deal with asynchronous event chains using Fluint as a
design guide.

2) Consider integrating Hamcrest, or at least look more closely at how it
may improve our own recommended workflow.

3) Investigate writing an Eclipse plugin that lets us generate classes and
test cases more easily within the IDE, and write a new printer/runner that
emits results into the Flash/Flex Builder test output. This could actually
be a separate project that anyone could contribute.

I'd welcome any input on these ideas and concede that I may well be missing
something critical in any of the above points.

Anyone out there agree or disagree?


Thanks,

Luke

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[sam / p. <sa...@pi...>]

The new file wizards are fairly easy to write. Not sure about hooking into
the flash builder swt test runner ui though.
sr

On Sun, Jun 14, 2009 at 6:18 PM, Luke Bayes <lb...@pa...> wrote:

> I did some digging this weekend into FlexUnit 4 sources, implementations
> and metadata / annotations in MXMLC.
>
> One major problem I have with metadata tags is that they can only be
> discovered at runtime for public members. I imagine there are hooks in the
> compiler that make [Bindable] and [Embed] work even for
> private/protected/namespaced members, but getting into runtime, custom tags
> means we have access only to public members that are visible to
> describeType.
>
> This is a little annoying to me, because I value having private / protected
> features for set up and tear down, as well as test helpers with custom
> domain-specific assertions. It feels awkward to expose these methods as
> public everywhere.
>
> I'm also annoyed with metadata in that we don't have any reliable
> information about the 'order of declaration' which leads to ugly duplication
> like [Before(order=1)], [Before(order=2)], etc.
>
> Then there are of course the issues Robert uncovered around supporting
> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
> only compiler for which these tags have value.
>
> The worst news is that the FlexUnit 3 implementation (excluding the
> printers) had pretty limited Flex framework dependencies, all of which would
> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
> integrated the AsyncToken garbage along with Flex collections and Logging.
> Fluint (which is now also bundled) has extensive framework dependencies that
> are unlikely to be extricated without a major overhaul...
>
> My conclusions at this point are as follows:
>
> FlexUnit is now appropriately named and works only with projects that don't
> mind executing tests within a Flex application SWF.
>
> I'm not sure I really understand the true value of annotations when
> compared to inheritance... We could certainly gain many of the benefits
> (multiple setup/teardown, class-level setup/teardown, and custom assertions
> using inheritance and minor modifications to our existing code.
>
> I perceive the real value of the latest release of FlexUnit to actually be
> the following:
>
> 1) Fluint seems to do a great job of describing and handling asynchronous
> event sequences
>
> 2) Hamcrest seems to be helpful for mocking and stubbing features
>
> 3) Generators and test output integrated into Eclipse
>
> It might be a worthwhile endeavor for us to do the following:
>
> 1) Improve how we deal with asynchronous event chains using Fluint as a
> design guide.
>
> 2) Consider integrating Hamcrest, or at least look more closely at how it
> may improve our own recommended workflow.
>
> 3) Investigate writing an Eclipse plugin that lets us generate classes and
> test cases more easily within the IDE, and write a new printer/runner that
> emits results into the Flash/Flex Builder test output. This could actually
> be a separate project that anyone could contribute.
>
> I'd welcome any input on these ideas and concede that I may well be missing
> something critical in any of the above points.
>
> Anyone out there agree or disagree?
>
>
> Thanks,
>
> Luke
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[Luke B. <lb...@pa...>]

Hey Sam,
Thanks for looking into this!

I could be wrong, but I imagine the test runner UI is mainly just a socket
connection to a running service. At least that's my hope.... Anyone want to
investigate? Seems like the first place to looks would be the FlexUnit 4.x
branch in SVN?

I also want to reiterate that I'm open to discussion about priorities and
directions moving forward, if there is a constituency that disagrees with
what I proposed over the weekend, please feel free to debate. It's entirely
possible that I'm missing some key information or benefits about annotations
in AS3, and I'd rather not fall out of step with you - our users.


Thanks,

Luke




On Mon, Jun 15, 2009 at 9:19 AM, sam / pixelconsumption <
sa...@pi...> wrote:

> The new file wizards are fairly easy to write. Not sure about hooking into
> the flash builder swt test runner ui though.
> sr
>
> On Sun, Jun 14, 2009 at 6:18 PM, Luke Bayes <lb...@pa...>wrote:
>
>> I did some digging this weekend into FlexUnit 4 sources, implementations
>> and metadata / annotations in MXMLC.
>>
>> One major problem I have with metadata tags is that they can only be
>> discovered at runtime for public members. I imagine there are hooks in the
>> compiler that make [Bindable] and [Embed] work even for
>> private/protected/namespaced members, but getting into runtime, custom tags
>> means we have access only to public members that are visible to
>> describeType.
>>
>> This is a little annoying to me, because I value having private /
>> protected features for set up and tear down, as well as test helpers with
>> custom domain-specific assertions. It feels awkward to expose these methods
>> as public everywhere.
>>
>> I'm also annoyed with metadata in that we don't have any reliable
>> information about the 'order of declaration' which leads to ugly duplication
>> like [Before(order=1)], [Before(order=2)], etc.
>>
>> Then there are of course the issues Robert uncovered around supporting
>> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
>> only compiler for which these tags have value.
>>
>> The worst news is that the FlexUnit 3 implementation (excluding the
>> printers) had pretty limited Flex framework dependencies, all of which would
>> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
>> integrated the AsyncToken garbage along with Flex collections and Logging.
>> Fluint (which is now also bundled) has extensive framework dependencies that
>> are unlikely to be extricated without a major overhaul...
>>
>> My conclusions at this point are as follows:
>>
>> FlexUnit is now appropriately named and works only with projects that
>> don't mind executing tests within a Flex application SWF.
>>
>> I'm not sure I really understand the true value of annotations when
>> compared to inheritance... We could certainly gain many of the benefits
>> (multiple setup/teardown, class-level setup/teardown, and custom assertions
>> using inheritance and minor modifications to our existing code.
>>
>> I perceive the real value of the latest release of FlexUnit to actually be
>> the following:
>>
>> 1) Fluint seems to do a great job of describing and handling asynchronous
>> event sequences
>>
>> 2) Hamcrest seems to be helpful for mocking and stubbing features
>>
>> 3) Generators and test output integrated into Eclipse
>>
>> It might be a worthwhile endeavor for us to do the following:
>>
>> 1) Improve how we deal with asynchronous event chains using Fluint as a
>> design guide.
>>
>> 2) Consider integrating Hamcrest, or at least look more closely at how it
>> may improve our own recommended workflow.
>>
>> 3) Investigate writing an Eclipse plugin that lets us generate classes and
>> test cases more easily within the IDE, and write a new printer/runner that
>> emits results into the Flash/Flex Builder test output. This could actually
>> be a separate project that anyone could contribute.
>>
>> I'd welcome any input on these ideas and concede that I may well be
>> missing something critical in any of the above points.
>>
>> Anyone out there agree or disagree?
>>
>>
>> Thanks,
>>
>> Luke
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Asunit-users mailing list
>> Asu...@li...
>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[Robert P. <in...@ro...>]

Luke,

Thanks for this investigation; I wasn't aware of all those Flex
dependencies. I agree with your overall assessment and recommendations.

I've worked with Hamcrest a fair bit and I would love to work on integrating
it into AsUnit. I'll start another thread to discuss how to do that.

Robert


On Sun, Jun 14, 2009 at 3:18 PM, Luke Bayes <lb...@pa...> wrote:

> I did some digging this weekend into FlexUnit 4 sources, implementations
> and metadata / annotations in MXMLC.
>
> One major problem I have with metadata tags is that they can only be
> discovered at runtime for public members. I imagine there are hooks in the
> compiler that make [Bindable] and [Embed] work even for
> private/protected/namespaced members, but getting into runtime, custom tags
> means we have access only to public members that are visible to
> describeType.
>
> This is a little annoying to me, because I value having private / protected
> features for set up and tear down, as well as test helpers with custom
> domain-specific assertions. It feels awkward to expose these methods as
> public everywhere.
>
> I'm also annoyed with metadata in that we don't have any reliable
> information about the 'order of declaration' which leads to ugly duplication
> like [Before(order=1)], [Before(order=2)], etc.
>
> Then there are of course the issues Robert uncovered around supporting
> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
> only compiler for which these tags have value.
>
> The worst news is that the FlexUnit 3 implementation (excluding the
> printers) had pretty limited Flex framework dependencies, all of which would
> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
> integrated the AsyncToken garbage along with Flex collections and Logging.
> Fluint (which is now also bundled) has extensive framework dependencies that
> are unlikely to be extricated without a major overhaul...
>
> My conclusions at this point are as follows:
>
> FlexUnit is now appropriately named and works only with projects that don't
> mind executing tests within a Flex application SWF.
>
> I'm not sure I really understand the true value of annotations when
> compared to inheritance... We could certainly gain many of the benefits
> (multiple setup/teardown, class-level setup/teardown, and custom assertions
> using inheritance and minor modifications to our existing code.
>
> I perceive the real value of the latest release of FlexUnit to actually be
> the following:
>
> 1) Fluint seems to do a great job of describing and handling asynchronous
> event sequences
>
> 2) Hamcrest seems to be helpful for mocking and stubbing features
>
> 3) Generators and test output integrated into Eclipse
>
> It might be a worthwhile endeavor for us to do the following:
>
> 1) Improve how we deal with asynchronous event chains using Fluint as a
> design guide.
>
> 2) Consider integrating Hamcrest, or at least look more closely at how it
> may improve our own recommended workflow.
>
> 3) Investigate writing an Eclipse plugin that lets us generate classes and
> test cases more easily within the IDE, and write a new printer/runner that
> emits results into the Flash/Flex Builder test output. This could actually
> be a separate project that anyone could contribute.
>
> I'd welcome any input on these ideas and concede that I may well be missing
> something critical in any of the above points.
>
> Anyone out there agree or disagree?
>
>
> Thanks,
>
> Luke
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[sam / p. <sa...@pi...>]

I've decompiled Flex Builder before, I can do it again with Flash Builder
;). I'm guessing they use a version of the ant task that opens a socket and
waits for the junit report style xml to be sent across.
sr

On Mon, Jun 15, 2009 at 1:58 PM, Robert Penner <in...@ro...>wrote:

> Luke,
>
> Thanks for this investigation; I wasn't aware of all those Flex
> dependencies. I agree with your overall assessment and recommendations.
>
> I've worked with Hamcrest a fair bit and I would love to work on
> integrating it into AsUnit. I'll start another thread to discuss how to do
> that.
>
> Robert
>
>
> On Sun, Jun 14, 2009 at 3:18 PM, Luke Bayes <lb...@pa...>wrote:
>
>> I did some digging this weekend into FlexUnit 4 sources, implementations
>> and metadata / annotations in MXMLC.
>>
>> One major problem I have with metadata tags is that they can only be
>> discovered at runtime for public members. I imagine there are hooks in the
>> compiler that make [Bindable] and [Embed] work even for
>> private/protected/namespaced members, but getting into runtime, custom tags
>> means we have access only to public members that are visible to
>> describeType.
>>
>> This is a little annoying to me, because I value having private /
>> protected features for set up and tear down, as well as test helpers with
>> custom domain-specific assertions. It feels awkward to expose these methods
>> as public everywhere.
>>
>> I'm also annoyed with metadata in that we don't have any reliable
>> information about the 'order of declaration' which leads to ugly duplication
>> like [Before(order=1)], [Before(order=2)], etc.
>>
>> Then there are of course the issues Robert uncovered around supporting
>> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
>> only compiler for which these tags have value.
>>
>> The worst news is that the FlexUnit 3 implementation (excluding the
>> printers) had pretty limited Flex framework dependencies, all of which would
>> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
>> integrated the AsyncToken garbage along with Flex collections and Logging.
>> Fluint (which is now also bundled) has extensive framework dependencies that
>> are unlikely to be extricated without a major overhaul...
>>
>> My conclusions at this point are as follows:
>>
>> FlexUnit is now appropriately named and works only with projects that
>> don't mind executing tests within a Flex application SWF.
>>
>> I'm not sure I really understand the true value of annotations when
>> compared to inheritance... We could certainly gain many of the benefits
>> (multiple setup/teardown, class-level setup/teardown, and custom assertions
>> using inheritance and minor modifications to our existing code.
>>
>> I perceive the real value of the latest release of FlexUnit to actually be
>> the following:
>>
>> 1) Fluint seems to do a great job of describing and handling asynchronous
>> event sequences
>>
>> 2) Hamcrest seems to be helpful for mocking and stubbing features
>>
>> 3) Generators and test output integrated into Eclipse
>>
>> It might be a worthwhile endeavor for us to do the following:
>>
>> 1) Improve how we deal with asynchronous event chains using Fluint as a
>> design guide.
>>
>> 2) Consider integrating Hamcrest, or at least look more closely at how it
>> may improve our own recommended workflow.
>>
>> 3) Investigate writing an Eclipse plugin that lets us generate classes and
>> test cases more easily within the IDE, and write a new printer/runner that
>> emits results into the Flash/Flex Builder test output. This could actually
>> be a separate project that anyone could contribute.
>>
>> I'd welcome any input on these ideas and concede that I may well be
>> missing something critical in any of the above points.
>>
>> Anyone out there agree or disagree?
>>
>>
>> Thanks,
>>
>> Luke
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Asunit-users mailing list
>> Asu...@li...
>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[sam / p. <sa...@pi...>]

bingo,
http://opensource.adobe.com/svn/opensource/flexunit/branches/4.x/FlexUnit4CIRunner/src/org/flexunit/listeners/JUnitListener.as
sr

On Mon, Jun 15, 2009 at 2:15 PM, sam / pixelconsumption <
sa...@pi...> wrote:

> I've decompiled Flex Builder before, I can do it again with Flash Builder
> ;). I'm guessing they use a version of the ant task that opens a socket and
> waits for the junit report style xml to be sent across.
> sr
>
>
> On Mon, Jun 15, 2009 at 1:58 PM, Robert Penner <in...@ro...>wrote:
>
>> Luke,
>>
>> Thanks for this investigation; I wasn't aware of all those Flex
>> dependencies. I agree with your overall assessment and recommendations.
>>
>> I've worked with Hamcrest a fair bit and I would love to work on
>> integrating it into AsUnit. I'll start another thread to discuss how to do
>> that.
>>
>> Robert
>>
>>
>> On Sun, Jun 14, 2009 at 3:18 PM, Luke Bayes <lb...@pa...>wrote:
>>
>>> I did some digging this weekend into FlexUnit 4 sources, implementations
>>> and metadata / annotations in MXMLC.
>>>
>>> One major problem I have with metadata tags is that they can only be
>>> discovered at runtime for public members. I imagine there are hooks in the
>>> compiler that make [Bindable] and [Embed] work even for
>>> private/protected/namespaced members, but getting into runtime, custom tags
>>> means we have access only to public members that are visible to
>>> describeType.
>>>
>>> This is a little annoying to me, because I value having private /
>>> protected features for set up and tear down, as well as test helpers with
>>> custom domain-specific assertions. It feels awkward to expose these methods
>>> as public everywhere.
>>>
>>> I'm also annoyed with metadata in that we don't have any reliable
>>> information about the 'order of declaration' which leads to ugly duplication
>>> like [Before(order=1)], [Before(order=2)], etc.
>>>
>>> Then there are of course the issues Robert uncovered around supporting
>>> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
>>> only compiler for which these tags have value.
>>>
>>> The worst news is that the FlexUnit 3 implementation (excluding the
>>> printers) had pretty limited Flex framework dependencies, all of which would
>>> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
>>> integrated the AsyncToken garbage along with Flex collections and Logging.
>>> Fluint (which is now also bundled) has extensive framework dependencies that
>>> are unlikely to be extricated without a major overhaul...
>>>
>>> My conclusions at this point are as follows:
>>>
>>> FlexUnit is now appropriately named and works only with projects that
>>> don't mind executing tests within a Flex application SWF.
>>>
>>> I'm not sure I really understand the true value of annotations when
>>> compared to inheritance... We could certainly gain many of the benefits
>>> (multiple setup/teardown, class-level setup/teardown, and custom assertions
>>> using inheritance and minor modifications to our existing code.
>>>
>>> I perceive the real value of the latest release of FlexUnit to actually
>>> be the following:
>>>
>>> 1) Fluint seems to do a great job of describing and handling asynchronous
>>> event sequences
>>>
>>> 2) Hamcrest seems to be helpful for mocking and stubbing features
>>>
>>> 3) Generators and test output integrated into Eclipse
>>>
>>> It might be a worthwhile endeavor for us to do the following:
>>>
>>> 1) Improve how we deal with asynchronous event chains using Fluint as a
>>> design guide.
>>>
>>> 2) Consider integrating Hamcrest, or at least look more closely at how it
>>> may improve our own recommended workflow.
>>>
>>> 3) Investigate writing an Eclipse plugin that lets us generate classes
>>> and test cases more easily within the IDE, and write a new printer/runner
>>> that emits results into the Flash/Flex Builder test output. This could
>>> actually be a separate project that anyone could contribute.
>>>
>>> I'd welcome any input on these ideas and concede that I may well be
>>> missing something critical in any of the above points.
>>>
>>> Anyone out there agree or disagree?
>>>
>>>
>>> Thanks,
>>>
>>> Luke
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Asunit-users mailing list
>>> Asu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Asunit-users mailing list
>> Asu...@li...
>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>
>>
>

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[sam / p. <sa...@pi...>]

Hit return too fast, that is just the updated ant task but I think we all
agree that the only way they are doing this is a socket for the flash
builder swt ui.
sr

On Mon, Jun 15, 2009 at 2:20 PM, sam / pixelconsumption <
sa...@pi...> wrote:

> bingo,
> http://opensource.adobe.com/svn/opensource/flexunit/branches/4.x/FlexUnit4CIRunner/src/org/flexunit/listeners/JUnitListener.as
> sr
>
>
> On Mon, Jun 15, 2009 at 2:15 PM, sam / pixelconsumption <
> sa...@pi...> wrote:
>
>> I've decompiled Flex Builder before, I can do it again with Flash Builder
>> ;). I'm guessing they use a version of the ant task that opens a socket and
>> waits for the junit report style xml to be sent across.
>> sr
>>
>>
>> On Mon, Jun 15, 2009 at 1:58 PM, Robert Penner <in...@ro...>wrote:
>>
>>> Luke,
>>>
>>> Thanks for this investigation; I wasn't aware of all those Flex
>>> dependencies. I agree with your overall assessment and recommendations.
>>>
>>> I've worked with Hamcrest a fair bit and I would love to work on
>>> integrating it into AsUnit. I'll start another thread to discuss how to do
>>> that.
>>>
>>> Robert
>>>
>>>
>>> On Sun, Jun 14, 2009 at 3:18 PM, Luke Bayes <lb...@pa...>wrote:
>>>
>>>> I did some digging this weekend into FlexUnit 4 sources, implementations
>>>> and metadata / annotations in MXMLC.
>>>>
>>>> One major problem I have with metadata tags is that they can only be
>>>> discovered at runtime for public members. I imagine there are hooks in the
>>>> compiler that make [Bindable] and [Embed] work even for
>>>> private/protected/namespaced members, but getting into runtime, custom tags
>>>> means we have access only to public members that are visible to
>>>> describeType.
>>>>
>>>> This is a little annoying to me, because I value having private /
>>>> protected features for set up and tear down, as well as test helpers with
>>>> custom domain-specific assertions. It feels awkward to expose these methods
>>>> as public everywhere.
>>>>
>>>> I'm also annoyed with metadata in that we don't have any reliable
>>>> information about the 'order of declaration' which leads to ugly duplication
>>>> like [Before(order=1)], [Before(order=2)], etc.
>>>>
>>>> Then there are of course the issues Robert uncovered around supporting
>>>> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
>>>> only compiler for which these tags have value.
>>>>
>>>> The worst news is that the FlexUnit 3 implementation (excluding the
>>>> printers) had pretty limited Flex framework dependencies, all of which would
>>>> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
>>>> integrated the AsyncToken garbage along with Flex collections and Logging.
>>>> Fluint (which is now also bundled) has extensive framework dependencies that
>>>> are unlikely to be extricated without a major overhaul...
>>>>
>>>> My conclusions at this point are as follows:
>>>>
>>>> FlexUnit is now appropriately named and works only with projects that
>>>> don't mind executing tests within a Flex application SWF.
>>>>
>>>> I'm not sure I really understand the true value of annotations when
>>>> compared to inheritance... We could certainly gain many of the benefits
>>>> (multiple setup/teardown, class-level setup/teardown, and custom assertions
>>>> using inheritance and minor modifications to our existing code.
>>>>
>>>> I perceive the real value of the latest release of FlexUnit to actually
>>>> be the following:
>>>>
>>>> 1) Fluint seems to do a great job of describing and handling
>>>> asynchronous event sequences
>>>>
>>>> 2) Hamcrest seems to be helpful for mocking and stubbing features
>>>>
>>>> 3) Generators and test output integrated into Eclipse
>>>>
>>>> It might be a worthwhile endeavor for us to do the following:
>>>>
>>>> 1) Improve how we deal with asynchronous event chains using Fluint as a
>>>> design guide.
>>>>
>>>> 2) Consider integrating Hamcrest, or at least look more closely at how
>>>> it may improve our own recommended workflow.
>>>>
>>>> 3) Investigate writing an Eclipse plugin that lets us generate classes
>>>> and test cases more easily within the IDE, and write a new printer/runner
>>>> that emits results into the Flash/Flex Builder test output. This could
>>>> actually be a separate project that anyone could contribute.
>>>>
>>>> I'd welcome any input on these ideas and concede that I may well be
>>>> missing something critical in any of the above points.
>>>>
>>>> Anyone out there agree or disagree?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Luke
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>>> Check out the new simplified licensing option that enables unlimited
>>>> royalty-free distribution of the report engine for externally facing
>>>> server and web deployment.
>>>> http://p.sf.net/sfu/businessobjects
>>>> _______________________________________________
>>>> Asunit-users mailing list
>>>> Asu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Asunit-users mailing list
>>> Asu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>>
>>>
>>
>

Re: [Asunit-users] FlexUnit4 features and AsUnit direction

[Luke B. <lb...@pa...>]

Nice!
Thanks Sam -


Luke


On Mon, Jun 15, 2009 at 11:20 AM, sam / pixelconsumption <
sa...@pi...> wrote:

> bingo,
> http://opensource.adobe.com/svn/opensource/flexunit/branches/4.x/FlexUnit4CIRunner/src/org/flexunit/listeners/JUnitListener.as
> sr
>
>
> On Mon, Jun 15, 2009 at 2:15 PM, sam / pixelconsumption <
> sa...@pi...> wrote:
>
>> I've decompiled Flex Builder before, I can do it again with Flash Builder
>> ;). I'm guessing they use a version of the ant task that opens a socket and
>> waits for the junit report style xml to be sent across.
>> sr
>>
>>
>> On Mon, Jun 15, 2009 at 1:58 PM, Robert Penner <in...@ro...>wrote:
>>
>>> Luke,
>>>
>>> Thanks for this investigation; I wasn't aware of all those Flex
>>> dependencies. I agree with your overall assessment and recommendations.
>>>
>>> I've worked with Hamcrest a fair bit and I would love to work on
>>> integrating it into AsUnit. I'll start another thread to discuss how to do
>>> that.
>>>
>>> Robert
>>>
>>>
>>> On Sun, Jun 14, 2009 at 3:18 PM, Luke Bayes <lb...@pa...>wrote:
>>>
>>>> I did some digging this weekend into FlexUnit 4 sources, implementations
>>>> and metadata / annotations in MXMLC.
>>>>
>>>> One major problem I have with metadata tags is that they can only be
>>>> discovered at runtime for public members. I imagine there are hooks in the
>>>> compiler that make [Bindable] and [Embed] work even for
>>>> private/protected/namespaced members, but getting into runtime, custom tags
>>>> means we have access only to public members that are visible to
>>>> describeType.
>>>>
>>>> This is a little annoying to me, because I value having private /
>>>> protected features for set up and tear down, as well as test helpers with
>>>> custom domain-specific assertions. It feels awkward to expose these methods
>>>> as public everywhere.
>>>>
>>>> I'm also annoyed with metadata in that we don't have any reliable
>>>> information about the 'order of declaration' which leads to ugly duplication
>>>> like [Before(order=1)], [Before(order=2)], etc.
>>>>
>>>> Then there are of course the issues Robert uncovered around supporting
>>>> metadata in Authoring CS3, which pretty much means that today - MXMLC is the
>>>> only compiler for which these tags have value.
>>>>
>>>> The worst news is that the FlexUnit 3 implementation (excluding the
>>>> printers) had pretty limited Flex framework dependencies, all of which would
>>>> have been trivial to rip out. Unfortunately, FlexUnit 4 has tightly
>>>> integrated the AsyncToken garbage along with Flex collections and Logging.
>>>> Fluint (which is now also bundled) has extensive framework dependencies that
>>>> are unlikely to be extricated without a major overhaul...
>>>>
>>>> My conclusions at this point are as follows:
>>>>
>>>> FlexUnit is now appropriately named and works only with projects that
>>>> don't mind executing tests within a Flex application SWF.
>>>>
>>>> I'm not sure I really understand the true value of annotations when
>>>> compared to inheritance... We could certainly gain many of the benefits
>>>> (multiple setup/teardown, class-level setup/teardown, and custom assertions
>>>> using inheritance and minor modifications to our existing code.
>>>>
>>>> I perceive the real value of the latest release of FlexUnit to actually
>>>> be the following:
>>>>
>>>> 1) Fluint seems to do a great job of describing and handling
>>>> asynchronous event sequences
>>>>
>>>> 2) Hamcrest seems to be helpful for mocking and stubbing features
>>>>
>>>> 3) Generators and test output integrated into Eclipse
>>>>
>>>> It might be a worthwhile endeavor for us to do the following:
>>>>
>>>> 1) Improve how we deal with asynchronous event chains using Fluint as a
>>>> design guide.
>>>>
>>>> 2) Consider integrating Hamcrest, or at least look more closely at how
>>>> it may improve our own recommended workflow.
>>>>
>>>> 3) Investigate writing an Eclipse plugin that lets us generate classes
>>>> and test cases more easily within the IDE, and write a new printer/runner
>>>> that emits results into the Flash/Flex Builder test output. This could
>>>> actually be a separate project that anyone could contribute.
>>>>
>>>> I'd welcome any input on these ideas and concede that I may well be
>>>> missing something critical in any of the above points.
>>>>
>>>> Anyone out there agree or disagree?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Luke
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>>> Check out the new simplified licensing option that enables unlimited
>>>> royalty-free distribution of the report engine for externally facing
>>>> server and web deployment.
>>>> http://p.sf.net/sfu/businessobjects
>>>> _______________________________________________
>>>> Asunit-users mailing list
>>>> Asu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Asunit-users mailing list
>>> Asu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/asunit-users
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>