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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
