On Tue, Feb 17, 2009 at 2:27 AM, Lex Spoon sp...@google.com wrote:
Revision 3901 broke -noserver hosted mode, but it took weeks before
anyone even noticed. I've been trying to figure out how to write a
regression test to prevent that sort of thing from happening.
Attached is a patch that I believe does the trick. Hosted mode gurus,
as well as people who know the GWTTestCase infrastructure, would be
very welcome to chime in on the right way to do this!
I figure that a -noserver hosted mode test is actually pretty close to
the existing hosted mode tests. There are just two differences I see.
First, a compile needs to actually run. Second, all auto-generation
of resources should be disabled in the GWTShellServlet. By turning
off all auto-generation, the servlet can pretend to be a dumb web
server that knows nothing about GWT.
What the patch does is add a new run style called -noserver. This is
a subclass of the regular hosted mode run style that includes the
above two changes. The trickiest part is that RunStyle now has a
parameter on whether auto-generation should happen with the embedded
server. This parameter had to be passed all the way from RunStyle to
JUnitShell to GWTShell to EmbeddedTomcatServer to GWTShellServlet.
Any simpler idea would be welcome.
Because it's easy, the patch also turns off resource generation for
web mode tests. The reasoning is that it's a slightly better test of
web mode to prefer the files that actually resulted from compilation.
To get the test hooked into the build scripts, I added ant
test.noserver in the user directory, and had this called when ant
test is called. There is only one test that this runs: the
IFrameLinkerTest. The other linkers don't work in noserver mode.
Also, no other tests are run in noserver mode; I don't see a
significant benefit to running the other ones this way, because once
an app is booted up everything will be identical to regular hosted
mode.
John, if the general strategy looks good to everyone, could you review
the implementation?
Passing the parameter all the way down this way is ugly, but I don't know of
any better ways to do it.
I would prefer the new ArgHandler to be a top-level class, but I see the
others are inlined as well so I am ok with keeping it.
I don't see the build.xml changes for test.noserver.
Otherwise, LGTM.
Sorry this took so long.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
