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