harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: Long,long testcase name...
Date Fri, 14 Apr 2006 01:55:24 GMT
Leo Simons wrote:
> On Wed, Apr 12, 2006 at 10:49:19AM -0400, Geir Magnusson Jr wrote:
>> But....  these are the names of *test case methods*.
> Yes indeed. Lazy consensus works well when the thing we don't care about
> is the thing where we let the people that do care have their way with
> them, innit? Very efficient!
>> Can someone give me a use case where having this gibberish name really, 
>> practically, adds any value?
> No doubt that's not possible given certain definitions of use case, value,
> and practicality. If you're like me, you type Alt+Ctrl+T in IntelliJ while
> having a method-to-test selected and it generates the test case name. So
> there is a use case (me writing a test), quite a practical one, and the
> value is that it saves me from having to rename a method. My environment is
> set up well for this kind of convention. Arguably, that's not important
> since I'm not writing tests for harmony right now. And even less important
> since most developers arond here seem to be using eclipse.
> Similarly, I often try and keep my methods sorted alphabetically (again, a
> convention, chosen since IntelliJ can do it automatically). If you name tests
> after the method they test and after what they do to that method, it results
> in a nicely organised testcase. Also not very relevant here.
> But it might be "use cases". Sounds more like making good use of a
> "convention" (and here we enter the "convention over configuration" meme
> which nowadays you can't get away with without a reference to ruby on
> rails. Soon it'll be religious...).
> The only use case for a convention is that it is a convention. Qualifying
> one convention as gibberish makes me wonder what the qualification is for
> all the other stuff.
> Its simple. There are some people out there that do it like that, some tools
> that are tailored for use by those people, hence it is some sort of
> convention.
> There is probably a convention or two in all the tests that we have right
> now too. Apparently its gibberish-ish too, otherwise this thread would not
> be there.
Professional! :)
I remember a famous saying, the code must be written for reading. A good 
naming style may help developers read and understand. I don't care if 
its name are test1 or something else, but it may take someone new in 
Harmony into trouble. Make the code and test clear are helpful, not for 
ourselves, but for those new comers.
One day,  with Harmony spreading all over the world, I don't want to 
hear anyone saying: "Woo, who's that guy writing these tests named 
'test1,test2,test3',  it takes me a lot of time on understanding them, 
even a mid-school student can do better than this!"
I agreed that our naming convention must:
1. make it understandable for everyone, what does this method try to do, 
or at least contain a hint (most important)
2. easy to distinguish if there are some similar ones
3. as short/easy as possible for people to read
Any comments?
>> 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...
> I think I have just argued that what matters is that there is *a*
> convention. All I did was mention one that I knew of. I try not to invent
> any of my own. Urdu doesn't seem to be the right one, but it might be a
> lot of fun (like recursive acronyms, or pronouncing luni like "looney")!
> ciao!
Means "Goodbye?"  The first Italian word I've learned! :)
> ---------------------------------------------------------------------
> 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

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