harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Long,long testcase name...
Date Wed, 12 Apr 2006 14:49:19 GMT

Leo Simons wrote:
> On Wed, Apr 12, 2006 at 08:09:41PM +0700, Mikhail Loenko wrote:
>> 2006/4/12, Andrew Zhang <zhanghuangzhu@gmail.com>:
>>> 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...


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

View raw message