Hi VELO, Issue created: https://issues.sonatype.org/browse/FLEXMOJOS-334
<https://issues.sonatype.org/browse/FLEXMOJOS-334>I have also implemented a patch with the below solution. Would it be possible to integrate this into the main distribution? It would help our team out quite a bit. Let me know if there's anything further that needs to be done here. Thanks, Jess On Mon, Jul 26, 2010 at 5:38 PM, Marvin Froeder <[email protected]> wrote: > Well, all set, now is just a matter of writing a jira ticket and wait for > someone willing to fix it. > > VELO > > On Mon, Jul 26, 2010 at 5:35 PM, Jesse Sightler > <[email protected]>wrote: > >> >> >> On Mon, Jul 26, 2010 at 3:57 PM, Marvin Froeder <[email protected]>wrote: >> >>> >>> >>> On Mon, Jul 26, 2010 at 4:42 PM, Jesse Sightler < >>> [email protected]> wrote: >>> >>>> On Mon, Jul 26, 2010 at 3:38 PM, Marvin Froeder <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> 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. >>>>> >>>> >>>> I'm not sure why that would be the case. Assuming that the entire swf >>>> is instrumented, and that the instrumentation knows how many class files >>>> are >>>> in the SWF (and thus a correct line count), then only the lines actually >>>> run >>>> would be shown as covered. >>>> >>>> If I placed the "new App()" line in a method that is never called (a >>>> common way to force inclusion without actually executing the codepath), >>>> then >>>> the swf should include all relevant classes, but only the lines actually >>>> run >>>> by my test case(s) would be excersized. >>>> >>> >>> The key word here is IF, if you add..... this manual actions users tend >>> to forget. >>> >> >> I agree with that risk assesment. I believe that it could be adequately >> addressed by leaving the default to the current configuration. For simple >> projects where there are no includes or other non-compilable files, the >> default behaviour insures solid accuracy (as intended). >> >> But for the case where people need to dig through the documentation and >> turn it off (often large projects, with lots of team members), the option >> would be here to provide something which is currently not possible. >> >> Honestly, I wish our codebase weren't in a shape that requires a feature >> like this, but I suspect I am not the only person who would benefit greatly >> from this enhancement. >> >> Thanks, >> Jess >> >> >> >> >>> >>> >>>> >>>> Then, the report should be correct, based upon the actual classes in the >>>> SWF. >>>> >>>> Or am I missing something about the way in which apparat calculates line >>>> count? Ie, why should the apparat report include lines that are never >>>> executed at all because of this change? >>>> >>>> Thanks, >>>> Jess >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> 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 <velo.br@ >>>>>>>> gmail.com> 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]<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]<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/
