harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "LvJimmy´╝îJing" <firep...@gmail.com>
Subject Re: Long,long testcase name...
Date Thu, 13 Apr 2006 01:33:03 GMT
2006/4/12, Geir Magnusson Jr <geir@pobox.com>:
>
>
>
> 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.


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.

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. 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?:)
Thank you for your comments!


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


--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message