On Mon, Oct 6, 2008 at 1:32 PM, Mike Aizatsky <[EMAIL PROTECTED]>wrote:
> > - Could briefly summarize the motivation for the > > suite()/JJSOptimizerTestDecator design? > > This way the module will be compiled only once. Unfortunately > JavaToJavaScriptCompiler doesn't have any easily extract compiling > pass and I didn't want to seriously refactor it. > I'm not sure I totally understand. Are you suggesting that if you don't use a suite and simply run the test class as a unit test, stuff happens multiple times that shouldn't? > > - JJSOptimizerTestCase.staticJprogram strikes me as scary.. is this > > necessary? > > How else would you pass values from static context? > Why do we need to pass in values from a static context exactly? > > - Textual comparison seems like a great first step, but a bit brittle > going > > forward. I'd worry that changes in the compiler totally unrelated to an > > optimization pass would tend to unnecessarily break tests. > > That's a valid point and I saw this in the fast. I don't know a > solution for this. Writing manual tree-based checks is even more > fragile. However I do believe this is better than nothing. > I know. But I would like to think of a way forward. Maybe we could take a "before" and "after" string snapshot of the program, and validate only the sections of the code that are different. > > - Very high-level: We should talk about doing something more invasive to > > make testing lighter weight. There's really no reason to have to setup a > > GWT module to do a test... with some refactoring we could make it as easy > as > > providing some input source and some output source. > > There still be a compilation step, right? Are you sure it will be easy > to set up all binding, intrinsic stuff, etc. without the module? > We should be able to get by without deferred binding, so it's really just providing the core JRE classes. Typically in other parts of the system, we just create reusable mock compilation units for things like Object, String; and write other test classes with minimal dependencies. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
