Fwd: Re: type anno test code check in

[Steve Sides]

A few things,
- Charile can clean up the tags and add some comments, probably to the 
help class mostly.  However, if you look at some of the recent tests 
going into jdk8, they're pretty darn hard to understand apart from some 
time of study. I think ease of test case extraction upon failure would 
help alleviate this.
- The tests have been reviewed many times on this mailing list, 
resulting the somehow hard to understand current form. :/
- Ability to extract a test case may have been one of my initial list of 
items(at least is usually is), but I'm pretty sure ease of diagnosis got 
lost in the maze of review directions and rewritings.
Charlie, see if there is a way to be able to more easily extract sample 
test case upon failure(have it spew the code for the particular test 
case under examination). It should be a bit easier to do since there 
appear to be some  failures.
-Jck just entered several bugs against these api's. You should check if 
your test failures match any open bugs.
-Please enter bugs with some reproducible test case if test failures 
don't match current open bugs...afterall, that is the goal of the tests 
(that also may have gotten a bit lost). :)  ; annotate the test(s) 
appropriately with @bug BUGID tags whether new or existing. ; Maybe  
even a separate smaller test case in the event of new failures.
- I think they would eventually go into jdk8/tl/jdk, right?

At this point, try to enter any new bugs with test cases as soon as you 
can.  That alone may help facilitate much of the above(other than fixing 
test tags).

Also,  I do not think someone has to be an author to be a 
contributor(???) and have code which they have written put back.

-steve




On 9/11/2013 7:44 AM, Joel Borggren-Franck wrote:
> Hi Charlie,
>
> These tests should go into TL, I can commit them there. The test review
> cycle should be on core-libs-dev at openjdk.java.net.
>
> However the test are not ready yet.
>
> If you run the tests vs jdk8-b106 or a recent copy of TL there is a fe
> failures. How can I as a developer see the exact source which caused the
> failure?
>
> Further, there is an @author tag between two jtreg tags, @build and
> @run in almost every file. Please don't do that.
>
> As ave a user of these tests there needs to be a way for me to:
>
> 1) Understand the tests / ensure that the tests are correct
> 2) Run the tests
> 3) Understand what causes tests failures
>
> Out of these only 2) is currently easy. 1) is hard and 3) looks
> impossible.
>
> Here is what you need to do to bring this forward:
>
> - At a minimum you need to document how the tests work. It is not clear
>    at the moment.
>
> - Please explain why are the helpers split out into 2 interfaces and 4
>    classes?
> - You also need to improve failure friendliness. If a tests fail, it
>    must be possible to see the java source of the generated program that
>    fails together with a decent explanation of what went wrong.
>
> If this is currently available, please indicate how to do it.
>
> cheers
> /Joel
>
> On 2013-09-11, Charlie Wang wrote:
>> Hi,
>>    I'm looking for a committer to help me check in type annotation
>> reflection test code. Could someone give me a hand?
>>
>>
>>
>> Thanks,
>> Charlie
>>
>> -------- Original Message --------
>> Subject: 	Re: type anno test code check in
>> Date: 	Tue, 10 Sep 2013 10:29:02 -0700
>> From: 	Alex Buckley <alex.buckley at oracle.com>
>> Organization: 	Oracle Corporation
>> To: 	Charlie Wang <charlie.wang at oracle.com>
>>
>>
>>
>> Ask on type-annotations-dev for a Committer in the Type Annotations
>> Project to push the tests for you. The tests will go in the jdk repo.
>>
>> Alex
>>