harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: Long,long testcase name...
Date Wed, 12 Apr 2006 09:46:04 GMT
Geir Magnusson Jr wrote:
>
>
> Paulex Yang wrote:
>> Geir Magnusson Jr wrote:
>>> testRequestPasswordAuthentication1()
>>>
>>> I mean, why do we want to embed all that crap in the testcase name?  
>>> Who cares?  The only person that will care is someone fixing when a 
>>> testcase breaks, and they'll read the code...
>>>
>> IMHO, the information is also useful when someone want to do some 
>> work like upgrade, he may need to know if there is any test cases for 
>> the requestPasswordAuthention(blabla...). But I agree that the 
>> current naming convention almost lost its value because it is so 
>> difficult for human reading. Maybe this information can be provided 
>> in other ways, like annotation.
>
> Upgrade what?  
Like upgrade current codes in SVN to Java 1.5 compatible(much of them 
are considered as 1.4 compatible or so, aren't them?)
> I think that this is a one-off kind of check people will do - if you 
> want to know coverage for   <Class>.<method>(<args>) you will ... 
> search for it? :)
Yes, I'll search for it in Eclipse by ctrl+o and input method name to 
see if what I want to test has been included, in fact I always do like 
this, and of course I'll use coverage tool as reference, too. I'm not 
expert on test theory, and I don't want to argument on the theory, but 
the theory as well as my own experience tell me that LOC coverage is not 
enough(AFAIK, most coverage tool only provides LOC coverage info). The 
developer always needs to check if test codes is satisfying enough based 
on coverage result before he wants to modify sth. And some naming 
convention is convenient at that time.

I agree that current naming convention is far from perfect and, IMHO, I 
don't like it, but naming convention itself is not evil but beneficial, 
and for sure the benefit is not limited in what I mentioned. In fact, 
the testAuthentication1 itself is a convention, but IMHO, the 
information it provides is acceptable but not enough. So I think the 
current issue is what the convention should looks like, and of course, 
there are trade-offs, we should try our best to make it convenient in 
most cases for most of us. So, ideas and your choice?
>
> What would an annotation do for you?
With annotation as metadata, a similar code review function which can 
recognize annotation is easily to be implemented and be integrated into 
IDE like Eclipse. It can provide same convenience like current ctrl+o, 
at same time we don't need to write/read/ignore the long, long test 
method name.
>
> geir
>
>>> geir
>>>
>>>
>>> LvJimmy´╝îJing wrote:
>>>> Hi all:
>>>>
>>>>     Following our testcase naming convention, I've find a name as: 
>>>> (hope it
>>>> won't break your screen :))
>>>> public void
>>>> test_requestPasswordAuthentication_java_lang_String_java_net_InetAddress_int_java_lang_String_java_lang_String_java_lang_String_java_net_URL_java_net_Authenticator_RequestorType()

>>>>
>>>>     which is the testcase for
>>>> java.net.Authenticator.requestPasswordAuthentication(
>>>>             String rHost, InetAddress rAddr, int rPort, String 
>>>> rProtocol,
>>>>             String rPrompt, String rScheme, URL rURL,
>>>>             Authenticator.RequestorType reqType);
>>>> and the class has another two method named 
>>>> requestPasswordAuthentication,
>>>> and only this method take URL and RequestorType as its parameters.
>>>>     The name is somehow too long to see and read, and I guess we 
>>>> can find a
>>>> shorter one for it,
>>>> e.g.test_requestPasswordAuthentication_URL_RequestorType. As URL and
>>>> RequestorType can identify the exactly
>>>> method to test. Or a adjusted naming convention shall be take. Any 
>>>> opinions?
>>>>
>>>> -- 
>>>>
>>>> Best Regards!
>>>>
>>>> Jimmy, Jing Lv
>>>> China Software Development Lab, IBM
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message