On Fri, Aug 7, 2009 at 11:35 AM, Bruce Johnson<[email protected]> wrote:
> I would go back and push on your dismissal of option #2: tests that really
> do only run in certain modes. I think we're going to have to embrace that on
> many different levels, and perhaps we simply need to come up with better
> infrastructure for managing it.
That's a great list of examples you give! I'm now convinced we need
selective enabling of tests in at least some cases. Your list is just
too long and varied to rule them all out.
One place I would quibble about is compiler transforms that we
consider to be optimizations, because an optimization should preserve
behavior. Thus, a test case should not have any easy way to be
sensitive to the choice. Going back to the code splitting example, it
would be within spec for the code splitter *not* to generate a
download event for a particular split point, even though it's not that
clever right now. That flexibility makes it very hard to think up an
API for querying the code splitter's settings. Certainly "on" and
"off" isn't enough information, at least going forward.
Would anyone see anything bad, for the narrow code splitting example,
with adding a LWM event saying "split point requested, but code
already present"? This approach would mean I can finish up the
runAsync LWM patch on Monday or Tuesday.
> So, would it be too much of a digression to brainstorm about a uniform way
> to handle all these variations?
> We have @DoNotRunWith() right now. Could we generalize that to:
> @DoNotRunWhen(from=<deferred-bound-type>, to=<chosen-replacement-class>)
> such as
> @DoNotRunWhen(from=DOMImpl.class, to=DOMImplOpera.class)
> We'd have to figure out how to compose these using a decent syntax, but
> something like this seems like it might work. It would also mean that we'd
> have to introduce potentially artificial classes to represent optional modes
> that are just flags right now,
> including classes such as "AggressiveCompilerOptimizationsDisabled" or
> "CodeSplittingEnabled", etc.
Looks good to me. For the short term, how does it strike you to also
have a way to query config and binding properties? While it might not
be what we want in the long run, it looks very practical right now.
For example, "disable this test when user.agent=opera". Another
example would be, "disable this test if class metadata is off". Given
the near-term state of module specifications, querying the property
looks more direct than needing to define a class that corresponds to
them.
Also, while thinking about how to set up the annotations, "or" and
"and" would seem helpful in some cases. Run this test if the agent is
iphone *or* the agent is android. Run this test if the agent is
iphone *and* class metadata is on. So it would be good to include
them, or something equally powerful, in the supported annotations.
At Ian's suggestion, I just took a quick look at the JUnit 4
documentation, and they support an assumeThat() method that we could
mimic. The way it's used is that a test method or class can run
assumeThat(someExpression) as the first thing it does. If the
assumption fails, then the rest of the test simply doesn't run. Large
benefits of this approach are that it is very general, and that we
don't have to spec up and implement && and ||. Instead, the built-in
Java versions could be used:
// test a deferred binding result
assumeThat(!(GWT.create("com.google.gwt.user.DOMImpl") instanceof
DOMImplOpera));
// test a property
assumeThat(GWT.bindingPropertyIs("user.agent", "safari"));
// test two properties
assumeThat(
GWT.bindingPropertyIs("user.agent", "safari") &&
GWT.configurationPropertyIs("gwt.metadata.disabled", "false"));
On the downside, using assumeThat() means that the test runner still
has to run the tests. With annotations, the test runner can know
ahead of time which tests are relevant on which platforms. Would our
test runners make good use of that information? Enough to merit the
implementation time and the larger GWT user manual?
-Lex
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---