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 <[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]<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/
