LOL, that is fine. At least the attached patch there gets us past our problem for now.
We look forward to seeing a more official solution as well. :) Thanks, Jess On Mon, Jul 26, 2010 at 9:44 PM, Marvin Froeder <[email protected]> wrote: > You did convinced me this need an different approach, you just didn't > convinced me that the suggested one is the right one :P > > I need to think more about this problem. > > On Mon, Jul 26, 2010 at 9:45 PM, Jesse Sightler > <[email protected]>wrote: > >> 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 <velo.br@ >>>>>>>> gmail.com> 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]<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/
