Leo Simons wrote:
On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
2006/4/12, Andrew Zhang <[EMAIL PROTECTED]>:
Hello, geir,
Let's consider the case you mentioned.
I totally agree that "testRequestPasswordAuthentication1" is a BAD name,
Why?
There's a whole "movement" devoted to answering that question :-)
http://joe.truemesh.com/blog/000175.html
might be of interest. "1" implies there is a "2", but what is the difference
between "1" and "2"?
Trying at every point along the way to make code as readable and descriptive
as possible is good. Eg
http://www.jroller.com/page/lsd/20050826#natural_language_java_is_often
So you end up with names such as
testRequestPasswordAuthenticationThrowsAnExceptionOnNullArguments
or
testRequestPasswordAuthenticationAcceptsSimpleJohnDoeParameters
they are painful to type, but less painful than typing javadocs, and more
likely to get read than javadocs, and likely to get read a lot more than
written. Furthermore, if you have camel case searching, you can search for
tRPA and get all the relevant bits.
But.... these are the names of *test case methods*.
Lets get practical for just a second - test code is different than the
target code (for lack of a better term).
Target code is the whole reason for existing - it's what people work in
day in and day out. You are constantly cross-referencing, refactoring,
etc, etc, etc. Code readability and convention is critical.
Test code, especially unit tests of the implementation test type, are
usually simple, one-shot, write-it-and-never-look-back code. True, this
code should be clear, clean, efficient and such in the event of a
failure so the person chasing down the failure can figure out what is
going on, but that's the only time you'll look at it, short of a
refactoring of the target code, which I'd bet anyone $100 that in that
case, you are going to let the IDE find and identify usages of the thing
being refactored anyway (if the IDE's refactoring support doesn't suck.)
How often do you go rummaging through the test cases when nothing is
wrong? If you do, would you like something else to do? :)
We are going to have *thousands upon thousands* of test cases, 99% we'll
never look at again.
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...
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...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
