Okay, I recently wrote a test for runAsync lightweight metrics, but -- oops -- that test fails in draft mode. In draft mode, no code splitting happens, so no events are generated, and so the test rightfully complains. So, what should be done?
I'm thinking to have draft mode generate some different events, and am wondering what people think. My first thought was to leave the events alone, because after all there are no actual downloads in draft mode. However, there are several problems with that approach: 1. The test really should fail if no events are generated in regular compilation modes. So it wouldn't be good to simply change the test to tolerate a complete lack of events. 2. It's awkward to have a test that only runs in certain compilation modes. The list of exceptions would have to live somewhere, and where would that be? 3. It's also awkward to have the test disable itself, because it needs to query some API to figure out whether code splitting really happened. What API would that be? "Am I in draft compile mode"? "Did code splitting happen for real"? I can't think of an API that wouldn't be fragile. It's fully intended that the compiler is flexible in the kinds of optimization it does, and it should be possible for the code splitter to have its own decision making as well. It would be better if this test were robust against such changes. Further, the API would be hard to keep private to the test; application code might start using it, thus locking GWT into supporting it for some amount of time. So, instead of enabling the test selectively, how about generating a different event when in draft compile mode? The current event sequence for calling a single runAsync is as follows: - leftoversDownload -- download of the leftovers fragment - download1 --- download of code for split point 1 - runCallbacks1 -- run the callbacks for split point 1 In draft compile mode, maybe the events could be like this: - codeAlreadyLoaded1 -- code for split point 1 requested but already present - runCallbacks1 -- run the callbacks for split point 1 I could then update the test to tolerate either sequence. Thoughts? Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
