On Fri, Aug 7, 2009 at 12:20 PM, Lex Spoon <sp...@google.com> wrote:
> 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.
The sorts of compiler optimizations tests I was referring to were
to-be-written tests of complex optimizations where the whole point of the
test is to ensure the compiler is doing exactly the transform we intend it
to. IOW, the sort of stuff Scott is working on testing infrastructure for.
I mostly see your point about the splitter, and in cases like that where you
aren't trying to test the exact decisions/implementation, then it seems
reasonable to have something that's a bit looser. OTOH, one could argue that
it's good to have tests that verify specific behavior that is intended for
the current implementation rather than adherence to the spec.
> 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.
No objections here, especially if the "code already present" event is
meaningful for web
mode where indeed the needed code has already been downloaded. That
could be useful thing to know at runtime in production.
> 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.
I like the pragmatism, but I fear the repercussions of a "intermediate
generalized" solution that would encouraged the string literal names of
properties and flags all over client code. I'd rather we switched things
over to The Right Way (whatever we deem that to be) rather than have a
half-done waypoint. However, The Right Thing could be something very
different than what I proposed -- see the JUnit discussion below.
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.
My idea here might be considered a hack. I was thinking that "and" could be
represented as pairs of (to, from) tuples, and that "or" could be
represented as separate test cases that simply delegate, such as
@RunWhen(Browser.class, Browser_IPhone.class)
public void testIPhone() {
doTestIPhoneOrAndroid();
}
@RunWhen(Browser.class, Browser_Android.class)
public void testAndroid() {
doTestIPhoneOrAndroid();
}
private void doTestIPhoneOrAndroid() {
...
}
Now that I look at it, it's kinda hacky, but then again it may not be very
common. Hopefully not, or we're not doing a good job of creating portable
APIs.
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?
I think assumeThat() might indeed be a good general solution, along the
lines of your examples. It subsumes the annotations I proposed, and it's
nice that it could be generalized easily to any sort of tests. Also, it
*might* be possible for the compiler to optimize it statically somewhat such
that if a test contained "assumeThat(X)" where X was statically know to be
false, the whole method could go away. (Of course, we'd need that behavior
to be generalized somehow -- I'm not proposing JUnit-specific compiler
behavior, which would be way too hacky).
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
