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