I like the updated test code. Thanks!
Xuelei
On 9/22/2018 11:33 AM, Jamil Nimeh wrote:
Hi Brad, Xuelei, et al.,
Thanks for all your comments. I've udpated the test with Brad's
findings and made it use separate @run lines for each test as Xuelei
requested.
Webrev: http://cr.openjdk.java.n
Hi Brad, Xuelei, et al.,
Thanks for all your comments. I've udpated the test with Brad's
findings and made it use separate @run lines for each test as Xuelei
requested.
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.02
--Jamil
On 09/21/2018 02:35 PM, Jamil Nimeh wrote:
IIRC/AIUI, jtreg only outputs standard output test run information when
tests fail. This brings down the amount of test info a lot.
To find the failing case, you just have to grep for:
^TEST RESULT:.*FAIL
Brad
On 9/21/2018 5:23 PM, Jamil Nimeh wrote:
Thanks Xuelei.
You make a good poi
Thanks Xuelei.
You make a good point about the debug logs losing information when they
get large. We have a lot of tests, more than a couple I wrote, where we
do multiple tests in a single execution. In most cases it works pretty
nicely, but admittedly when the logs get really long then I ha
> On Sep 21, 2018, at 4:45 PM, Jamil Nimeh wrote:
>
> Hi Xuelei,
>
> I started getting into making the one test per run approach - having these
> controlled from command line args in the run line gets a little weird after a
> while. We have different hello messages that are byte arrays, so
Hi Xuelei,
I started getting into making the one test per run approach - having
these controlled from command line args in the run line gets a little
weird after a while. We have different hello messages that are byte
arrays, so you have to map them to strings (easy), but then some test
case
Hi Brad, thanks for the review. Comments in-line.
On 9/21/2018 4:20 PM, Bradford Wetmore wrote:
Take my "personal preference" comments with a grain of salt.
This test may be part of a test template, so if some of my comments
(e.g. 340/412) are because of your test modification, you can ignore
I had the same initial thought, but he is actually outputting the
exception where it occurs, and only failing at the end. So 4 failures
will have 4 exceptions output.
Brad
On 9/21/2018 3:55 PM, Xuelei Fan wrote:
Once there is a test case failed, it may be not straightforward to
identify whi
Take my "personal preference" comments with a grain of salt.
This test may be part of a test template, so if some of my comments
(e.g. 340/412) are because of your test modification, you can ignore them.
CliHelloProcessing.java
---
My personal preference is to have the nam
On 9/21/2018 4:00 PM, Jamil Nimeh wrote:
Are you suggesting having multiple run lines or something like that? I
think we could do that.
I would prefer to to the run lines.
I would like to have it run all cases rather
than short-circuit on the first failure, as each case doesn't depend on
the
Are you suggesting having multiple run lines or something like that? I
think we could do that. I would like to have it run all cases rather
than short-circuit on the first failure, as each case doesn't depend on
the others. Let me play around with the run directives and see if we
can make it
Once there is a test case failed, it may be not straightforward to
identify which one is failed. Especially, currently, the testing blog
may be swallowed if it is too long. Would you please consider one case
per test? Or break immediately if a test case failed, instead of
waiting for all to
Hello all,
This adds a test that lets us send different kinds of client hellos to a
JSSE server. It can be extended to handle different kinds of corner
cases for client hello extension sets as well as fuzzing test cases in
the future. It also provides some extra test coverage for JDK-8210334
13 matches
Mail list logo
