P3 Description
Brief summary: for JDTS we need JT harness ability to show reason not only for filter, but for particular test oalso.
The problem is discussed with Brian , and we agreed that the suggested solution (add method TestFilter#getReason(TestDescription td)) is possible to implement.
Details are in e-mail below.
Was not implemented in JDTS 2.4 due to lack of time.
---------------------
Let's do it through the contribution process. It will be a good exercise. :)
I agree to the concept, but would like to make some comments about the API. Could you start a discussion on java.net, saying what you would like to do? Basically what you said below...
http://forums.java.net/jive/forum.jspa?forumID=108
Thanks!
Brian
Ivan A. Veselovsky wrote:
> Hi, Brian,
> let's please clarify the status of this discussion.
> does your team plan to make this improvement, or can JDTS team do it and contribute via open source contrib mechanism?
> thanks.
> --ivan
>
> Ivan A. Veselovsky wrote:
>
>> Hi, Brian,
>> thanks for fast reply.
>>
>> Is that possible to contribute this change to JTH through the open-source review machanism (I think, this is the fastest and easiest way), or do you prefer somebody from your team to implement this RFE?
>> Should I file an RFE CR on that?
>> Also, is there a chance to have this implemented in the nearest version of JTH?
>>
>> About performance -- I dont think there is an issue there because in the simplest situation TestFilter#getReason(TestDescription) may return null, what means that default TestFilter#getReason() should be used. Such situation has near zero performance impact.
>> Other situations of non-trivial implementations of TestFilter#getReason(TestDescription) are fully under the filter's developer responsibility, e.g. a proper result caching inside TestFilter object may help to prevent the possible performance decrease.
>>
>> many thanks.
>>
>> --ivan
>>
>> Brian Kurotsuchi wrote:
>>
>>> I think it's technically easy. The main problem is performance (maybe?). Perhaps not - with intelligent rendering in GUI mode, we wouldn't need to call it too often (not 10000 times typically).
>>>
>>> I could see this done as a small RFE soon - it's not that much code. Especially if the JTable data model/rendering is already good enough.
>>>
>>> Brian
>>>
>>> Ivan A. Veselovsky wrote:
>>>
>>>> Hi, Brian,
>>>> can you please kindly dive us an advice on the following technical topic concerning Java Test Harness.
>>>>
>>>> We (JDTS team) now implement some custom filter (a subclass of com.sun.javatest.TestFilter) that may have some not obvious functionality specific for each particular testpack and test. By this reason we would like to provide the user with exact and comprehensive info on why each particular test is filtered out. But unfortunately current design of the class com.sun.javatest.TestFilter provides ability to get the filter out reason only for entire the filter, but not for each particular test.
>>>> As a solution we would like to suggest to add method com.sun.javatest.TestFilter#getReason(TestDescription) with the contract of returning the specific reason (or null if none) and use the returned value in the "Filter Out Reason" column in the Java Test UI.
>>>>
>>>> Does this suggestion looks reasonable for you from technical viewpoint?
>>>> Could it be helpful for other JavaTest Harness users?
>>>>
>>>> If the answers for the above 2 questions are positive, we can further discuss organisational issues, e.g. is that possible to contribute the change (that seems to be quite easy) made by JDTS team via the open-source contribution mechanism.
>>>>
>>>> Many thanks.
>>>>
>>>> --ivan
>>>>
The problem is discussed with Brian , and we agreed that the suggested solution (add method TestFilter#getReason(TestDescription td)) is possible to implement.
Details are in e-mail below.
Was not implemented in JDTS 2.4 due to lack of time.
---------------------
Let's do it through the contribution process. It will be a good exercise. :)
I agree to the concept, but would like to make some comments about the API. Could you start a discussion on java.net, saying what you would like to do? Basically what you said below...
http://forums.java.net/jive/forum.jspa?forumID=108
Thanks!
Brian
Ivan A. Veselovsky wrote:
> Hi, Brian,
> let's please clarify the status of this discussion.
> does your team plan to make this improvement, or can JDTS team do it and contribute via open source contrib mechanism?
> thanks.
> --ivan
>
> Ivan A. Veselovsky wrote:
>
>> Hi, Brian,
>> thanks for fast reply.
>>
>> Is that possible to contribute this change to JTH through the open-source review machanism (I think, this is the fastest and easiest way), or do you prefer somebody from your team to implement this RFE?
>> Should I file an RFE CR on that?
>> Also, is there a chance to have this implemented in the nearest version of JTH?
>>
>> About performance -- I dont think there is an issue there because in the simplest situation TestFilter#getReason(TestDescription) may return null, what means that default TestFilter#getReason() should be used. Such situation has near zero performance impact.
>> Other situations of non-trivial implementations of TestFilter#getReason(TestDescription) are fully under the filter's developer responsibility, e.g. a proper result caching inside TestFilter object may help to prevent the possible performance decrease.
>>
>> many thanks.
>>
>> --ivan
>>
>> Brian Kurotsuchi wrote:
>>
>>> I think it's technically easy. The main problem is performance (maybe?). Perhaps not - with intelligent rendering in GUI mode, we wouldn't need to call it too often (not 10000 times typically).
>>>
>>> I could see this done as a small RFE soon - it's not that much code. Especially if the JTable data model/rendering is already good enough.
>>>
>>> Brian
>>>
>>> Ivan A. Veselovsky wrote:
>>>
>>>> Hi, Brian,
>>>> can you please kindly dive us an advice on the following technical topic concerning Java Test Harness.
>>>>
>>>> We (JDTS team) now implement some custom filter (a subclass of com.sun.javatest.TestFilter) that may have some not obvious functionality specific for each particular testpack and test. By this reason we would like to provide the user with exact and comprehensive info on why each particular test is filtered out. But unfortunately current design of the class com.sun.javatest.TestFilter provides ability to get the filter out reason only for entire the filter, but not for each particular test.
>>>> As a solution we would like to suggest to add method com.sun.javatest.TestFilter#getReason(TestDescription) with the contract of returning the specific reason (or null if none) and use the returned value in the "Filter Out Reason" column in the Java Test UI.
>>>>
>>>> Does this suggestion looks reasonable for you from technical viewpoint?
>>>> Could it be helpful for other JavaTest Harness users?
>>>>
>>>> If the answers for the above 2 questions are positive, we can further discuss organisational issues, e.g. is that possible to contribute the change (that seems to be quite easy) made by JDTS team via the open-source contribution mechanism.
>>>>
>>>> Many thanks.
>>>>
>>>> --ivan
>>>>