Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <443CED6D.4070606@pobox.com>
Date: Wed, 12 Apr 2006 08:07:09 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Long,long testcase name...
References: <5c8e69f0604101940q6843d941n7ad41b05d78d3617@mail.gmail.com>
 <443B1CF7.5060003@pobox.com> <443B28A9.1070103@gmail.com>
 <443B809E.1010804@pobox.com> <443CCC5C.9000803@gmail.com>
In-Reply-To: <443CCC5C.9000803@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Paulex Yang wrote:
> 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?)

Sure - so what does having a multi-screen-wide test name do for you here?

>> 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.

Absolutely.  I've seen people use coverage as a developer success 
metric, and thus incentivize the wrong behavior - useless test cases 
that give you a false feeling of security.

> 
> 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?

Ok - I'm going to assume I'm missing something important.

What does this highly structure, formal naming convention for test cases 
buy us other than unpleasant code to work with?

Naming conventions are used for many reasons, which may be trivially 
summarized as 'making the code easier for humans to work with'.

So suppose I have the same testcase done your way, and done my way.  The 
question I'm going to ask is "Practically speaking, what does the 
multi-screen-name do for you that looking at a simple method name and 
signature doesn't?"

package org.apache.harmony.luni;

import java.net;

public void testRequestPasswordAuthentication1()
	throws Exception
{
       ...
	Authenticator.requestPasswordAuthentication( rHost, rAddr,
		rPort, rProtocol, rPrompt, rScheme, rURL, reqType);

       ...
}

public void testRquestPasswordAuthentication2()
	throws Exception
{
       ...
	Authenticator.requestPasswordAuthentication(rURL, reqType);
       ...
}

versus

package org.apache.harmony.luni;

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() 

	throws Exception
{
       ...
	Authenticator.requestPasswordAuthentication( rHost, rAddr,
		rPort, rProtocol, rPrompt, rScheme, rURL, reqType);

       ...
}

public void
test_requestPasswordAuthentication_java_net_URL_java_net_Authenticator_RequestorType() 

	throws Exception
{
       ...
	Authenticator.requestPasswordAuthentication(rURL, reqType);
       ...
}

Practically speaking, what does the multi-screen-name do for you that 
looking at a simple method name and signature doesn't?

I mean, you aren't going to be searching by the full string - you'd 
never type

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() 


into a search box in your editor, nor into a commandline for grep.

Sure, you may argue that scrolling down, it's easy to see the difference 
between the two for this example, but at this point, you are scrolling 
through the code, or searching for 'requestPasswordAuthe' anyway...

>>
>> 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.

You are suggesting that we us annotations for *editing* support? That's 
interesting.  I'm used to thinking about annotations for 
runtime/deployment/etc purposes, not editing. Is this really better than 
just searching?  (And I suspect you realize that I wouldn't want to 
design our processes around one specific IDE.. :)

geir


>>
>> 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
>>
>>
> 
> 

---------------------------------------------------------------------
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