On Fri, Aug 7, 2009 at 11:11 AM, Lex Spoonsp...@google.com wrote:
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,
There's a related issue for ClassObjectTest. It is sensitive to
whether or not the compiler is in -XdisableClassMetadata mode.
I've wanted to add some kind of build information to the
GeneratorContext that would allow Generators to get the command-line
flags so generators can be sensitive to
JUnit 4 has @Theory and @Assumption annotations that might help here.
I forget which does what, but one of them (probably @Assumption) can
say I believe X is true and it needs to be for my tests to pass, so
ignore these if it's false. If there was some way to expose a
predicate that was true
On Fri, Aug 7, 2009 at 11:35 AM, Bruce Johnsonbr...@google.com 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
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.
On Fri, Aug 7, 2009 at 1:30 PM, Bruce Johnson br...@google.com wrote:
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,
On Fri, Aug 7, 2009 at 10:30 AM, Bruce Johnsonbr...@google.com wrote:
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
