LvJimmy，Jing wrote:
2006/4/12, Geir Magnusson Jr <[EMAIL PROTECTED]>:
We are going to have *thousands upon thousands* of test cases, 99% we'll
never look at again.
To tell the truth, we do look back the test to find if there's anything
wrong, especially in regression tests. As a result, how to find a fail test
out of so many testcases, and understanding what it is doing and finally why
it fails here, is really a problem for us. In many testcases there're over
2000 or 3000 lines and 100 tests, less or more.
Yes, when they *break*. And how do you find the failed test? you look
at the name and the stacktrace. If I told you it was test12343532()
you'd find it just as quickly as if I told you it was
test_foo_bar_woogie_java_net_thing_exception_wuggawugga_parameter_string_int_boolean_jata_util_fwoppy()
because you'd just search for that 'token' in the file. Actually, you
probably would get the stacktrace and find it from there, in which case
the relevant information is the line number in the file :)
(And no, I'm not advocating calling anything test12312312312())
Can someone give me a use case where having this gibberish name really,
practically, adds any value? We have package and class to provide
namespace separation, so it isn't about being globally unique...
If I see a test report, and see a test failure, *I* am going to go open
that method in an editor and look at it. If it's called test1 or
test_a_b_c_d...._ad_nauseum, it doesn't really matter. The name could
be in Urdu for all I care, as the method name is a token to me - it's
what I use to identify the codeblock that is doing the valuable thing,
showing a failure. I'll need to read the codeblock anyway...
Yes,yes, I agree test_a_b_c_d is not good indeed. However it contains more
information than test1, telling what method is tested exactly.
But I can't believe that the detail of package, arguments and exception
provides you with information any more useful than knowing the test was
in "java.util" package, the class was TestMap and the name was testGet,
all of which are going to be represented in the test report.
(Probably a less than ideal example as it's not overloaded, but you get
my drift...)
Yes there're
symbols after all, but more than Urdu. The developers do care, in my
opinion, as they do not understand test1,but
test_RequestPasswordAuthentication_ThrowsAnExceptionOnNullArguments.In many
cases, test_a_b_c_d work properly.
In the end, I could argue it doesn't matter (since it could be in Urdu
for me...) but before we all waste the time to construct these 'tokens'
that have embedded meaning, I'd love to hear a use case...
We're trying to find it,right?:)
Well, that's my point. There isn't a compelling use case, and it will
be a burden to programmers.
I think a meaningful name that's reasonably short is sufficient. I'm
arguing that we're going to use things like stacktrace info when things
go wrong anyway, which means were going into the code when there's a
failure. I'm arguing that long complicated names mean nothing because
most people don't have an encyclopediac memory of the API down to subtle
differences in arg lists for overloaded methods.
So
testAuthenticateResponseAsync1()
testAuthenitcateResponseAsync2()
is enough to set expectations and context when going after a bug, since
you'll use line numbers from stacktraces anyway.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
