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] For more options, visit this group at http://groups.google.com/group/flex-mojos http://flexmojos.sonatype.org/
