Correct. I have created 'tests' directories on both the AS and JS frameworks, and plan to use FlexUnit for AS and Jasmine for JS unit testing. That covers the frameworks. I imagine we build pre- and postcompile tests for the project code as well.
And leaving out the intermediate step (i.e. have FalconJS directly output minified JS, or have FalconJS call the Closure Compiler directly as a post compile step) will only increase the difficulty in testing for and more importantly, debugging any issues in the output JS. Finally, not having intermediate (annotated) JS files will make it impossible to let the Closure Builder do it's magic. That magic is an important part of having a highly optimised final output. The Builder calculates the dependencies between the project code, the FlexJS JS framework and the Closure Library, allowing it to remove unused code (no penalty for using a large library of which you only use one method) and to minify all internal references, while the annotation prevents the renaming or even deletion of public interfaces. All in all, the "intermediate" step, at least for the first few versions looks to me like a valuable tool and a way to allow for speedy development of both projects as well as the frameworks. EdB On Thu, Dec 6, 2012 at 4:56 PM, Michael Schmalle <apa...@teotigraphix.com> wrote: > > Quoting Carol Frampton <cfram...@adobe.com>: > >> >> >> On 12/6/12 7 :49AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>> Mike, >>> >>> After I'm done fixing the mess I made in SVN, I'll start work on the >>> 'template', but here is the basic idea to get you started: I would >>> like the compiler to output "intermediate" JS, by which I mean "human >>> readable". My Publisher then takes this intermediate code and puts it >>> through the Google Closure Builder, which optimises and minifies it. >>> The advantage of having the "intermediate" step is that it makes >>> debugging much (MUCH) easier. It will allow us to write tests, >>> something that minified code won't. And it will let us run the code in >>> the various browser based tooling and have the output make sense. >> >> >> If you use an intermediate form to test how to you know there aren't bugs >> introduced by the publishing process? >> >> Carol > > > Isn't the publishing process the closure compiler which google has tests for > when it compiles out the minified optimized js? > > I probably have more time into investigating the corss compile code In > FalconJS and I have to say as it stands we don't even know if our compiler > is creating bugs in the output js. It seems Adobe was unit testing the js > but we don't have any of those tests. > > So its reasonable to think we need to have tests for js that is compiled by > FalconJS in the intermediate stage. > > > > > Mike > > -- > Michael Schmalle - Teoti Graphix, LLC > http://www.teotigraphix.com > http://blog.teotigraphix.com > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
