On Mon, Jul 26, 2010 at 4:25 PM, Jesse Sightler <[email protected]>wrote:

> Yes, I can see where this could get complicated (parsing link reports).
>  Perhaps an workaround would be to give the user the option to only compile
> classes directly referenced by TestRunner (and the test cases associated
> with it)?
>
> When done this way, I could add a reference to "new App()" in one of my
> test cases, and the Flex compiler would figure out the rest.
>

The problem letting flex compiler dealing with the problem is the coverage
report would be unreliable.... it will give you 100% of class coverage every
time....  even if you have ZERO tests.


>
> It would not help with some of the scenarios that you mention (as it would
> not include unused classes), but it would be perfect for our environment
> (and I suspect quite a few others as well).
>
> Obviously, parsing the link-report is an option as well, but that looks
> more difficult.
>
> Thanks,
> Jess
>
>
> On Mon, Jul 26, 2010 at 2:41 PM, Marvin Froeder <[email protected]> wrote:
>
>>
>>
>> On Mon, Jul 26, 2010 at 3:26 PM, Jesse Sightler <[email protected]
>> > wrote:
>>
>>> Hi VELO,
>>>
>>> I have attached a sample of why I think this solution is unworkable for a
>>> large number of projects out there.
>>>
>>> The key point in the sample (so that you don't have to open it to
>>> understand the problem) is that it contains a class file with an AS3 include
>>> directive.  Ie, the structure is as follows:
>>>
>>>    - src/main/flex
>>>       - App.as (uses an "include" to bring in sampleInclude.as)
>>>       - sampleInclude.as
>>>
>>> With the packaging set to swf, and the sourceFile set to App.as, the
>>> "compile" operation performs correctly.  However, "test" attempts to compile
>>> both App.as and sampleInclude.as separately.  This fails, as
>>> sampleInclude.as is only intended to be included in other files (never
>>> compiled by itself directly).
>>>
>>> The merits of this design (include files) are certainly debatable, but as
>>> I don't always win such debates ( ;) ), I would prefer that the tool be able
>>> to deal with this, and similar scenarios involving files within source
>>> control that are not compilable as well.
>>>
>>> Perhaps there could be an option to have it only compile the same source
>>> files that are compiled as part of the normal SWF generation?  That would
>>> solve the problem for me.  The coverage would also accurately reflect the
>>> statistics that I am interested in (ie, coverage of classes that are
>>> actually compiled into the swf).  I can understand your view as well,
>>> though, so perhaps this has to be optional.
>>>
>> That is the ideal fix, but the question at hand is, how? Do you know
>> anyway way to determine that (one that doesn't demand parsing link
>> reports)....
>>
>>
>>
>>>
>>> Are there any other workarounds that we can use at this point?
>>>
>>
>> No, not at the moment, but well, you can download the source, comment out
>> the include section until something fancy came up.
>>
>>
>>>
>>> Again, thanks for your response,
>>> Jess
>>>
>>>
>>> On Mon, Jul 26, 2010 at 12:57 PM, Marvin Froeder <[email protected]>wrote:
>>>
>>>> Coverage does need to include all src/main/flex classes into the test
>>>> SWF in order to produce reliable test results.  Otherwise it will always
>>>> reports 100% of classes coverage.
>>>> There is no other way to deal with that right now, but I'm open for
>>>> suggestions.
>>>>
>>>> Anyway, if you know that classes are broken, why don't you remove they
>>>> from src/main/flex or at least name they as .txt, .old or something else?!
>>>>
>>>>
>>>> VELO
>>>>
>>>> On Mon, Jul 26, 2010 at 1:21 PM, jsight <[email protected]>wrote:
>>>>
>>>>> I am attempting to run test classes and coverage reports on a fairly
>>>>> large SWF project.  The project compiles perfectly as long as there
>>>>> are no tests.
>>>>>
>>>>> If I include test classes in src/test/flex, the build of the actual
>>>>> app fails.
>>>>>
>>>>> All of the errors are on classes that would not normally be included
>>>>> in the SWF itself.  I cannot seem to control which classes from src/
>>>>> main get compiled.
>>>>>
>>>>> Is there a way to have it select the same classes as would normally be
>>>>> compiled without tests?
>>>>>
>>>>> The SWF compiles perfectly if the test files are not included at all,
>>>>> and it compiles ok before getting to the test phase of execution as
>>>>> well.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Flex Mojos" group.
>>>>> To post to this group, send email to [email protected]
>>>>> To unsubscribe from this group, send email to
>>>>> [email protected]<flex-mojos%[email protected]>
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/flex-mojos
>>>>>
>>>>> http://flexmojos.sonatype.org/
>>>>>
>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Flex Mojos" group.
>>>> To post to this group, send email to [email protected]
>>>> To unsubscribe from this group, send email to
>>>> [email protected]<flex-mojos%[email protected]>
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/flex-mojos
>>>>
>>>> http://flexmojos.sonatype.org/
>>>>
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Flex Mojos" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]<flex-mojos%[email protected]>
>> For more options, visit this group at
>> http://groups.google.com/group/flex-mojos
>>
>> http://flexmojos.sonatype.org/
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Flex Mojos" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<flex-mojos%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/flex-mojos
>
> http://flexmojos.sonatype.org/
>

-- 
You received this message because you are subscribed to the Google
Groups "Flex Mojos" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/flex-mojos

http://flexmojos.sonatype.org/

Reply via email to