RFR(M): 8160299 - Test8015436 doesn't check which method was executed

[Vladimir Kozlov]

Good, this what I wanted to hear. Agree.

Thanks,
Vladimir

On 8/8/16 12:31 PM, dmitrij pochepko wrote:
> I'm trying to follow unified approach. We have a number of tests
> following both schemes: few testclasses launch themselves in different
> modes(driver and test) and a number of tests has separate driver. I
> remember SQE locally discussed that separate launcher/driver file is
> preferrable to improve readability(also, in case we have exception in
> test code, sometimes it takes time to understand which vm stacktrace
> belongs to) and so an approach with separate driver prevails.
>
> Thanks,
> Dmitrij
>
> On 08.08.2016 21:24, Vladimir Kozlov wrote:
>> On 8/8/16 11:22 AM, dmitrij pochepko wrote:
>>> Thank you for attentive review.
>>>
>>>
>>> oa = ProcessTools.executeTestJvm(Test8015436.class.getName());
>>>
>>> this call forks another vm, wait for exit and provide output for
>>> analyzing.
>>> So, basically Driver8015436 is just a wrapper for original Test8015436
>>
>> Yes, I know that. I just asked was it easier to do than modifying the
>> test itself and do not add an other file?
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Thanks,
>>> Dmitrij
>>>
>>>
>>> On 08.08.2016 20:45, Vladimir Kozlov wrote:
>>>> Changes seem fine. Why not use fork and look on result of forked VM?
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 8/8/16 6:37 AM, Dmitrij Pochepko wrote:
>>>>> Hi,
>>>>>
>>>>> please review fix for 8160299 - Test8015436 doesn't check which method
>>>>> was executed
>>>>>
>>>>> Test wasn't strict enough and test output which reflects main test
>>>>> logic
>>>>> was unchecked. This fix adds simple driver class which performs
>>>>> respective output checks.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8160299/webrev.01/
>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8160299
>>>>>
>>>>> I've tested this fix on linux-amd64.
>>>>>
>>>>> Thanks,
>>>>> Dmitrij
>>>
>