• Post Reply Bookmark Topic Watch Topic
  • New Topic

Minor question - using long method names in test code  RSS feed

 
Ali Gordon
Ranch Hand
Posts: 182
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is about Java and not about Junit. In a Junit book "Practical Unit Testing with JUnit and Mockito", the author encourages us to use descriptive method names like , even if they are too long and ugly. Is this really acceptable to professional software developers ? Would it not be better to use one line comments and a short test method name like constructorIllegalArgs... ?
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37518
554
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like the long method names. Comments tend to get out of sync. Ugly is in the eyes of the reader.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, this is in the context of writing test methods where longer names that describe the test would be advantageous.
 
Tim Cooke
Marshal
Posts: 4051
239
Clojure IntelliJ IDE Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An advantage of using descriptive test method names is observed when a test fails. Your CI server sends you an email with the following:


or

Which one contains more information? The first one right? The one with the longer method name. To me the second one is ambiguous and would require a trip to the test source code to even figure out what it's actually asserting. You may have a wonderfully descriptive comment attached to the short method name, but that text is never included in any test report so is not as useful as you'd think.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also remember that you never call test methods explicitly. They are called for you by the test framework. So you don't have these long method names cluttering up any of the rest of your code - they only appear as method signatures.

In fact (following a tip I saw at a conference that I liked), I actually break the usual naming convention for these methods and used _ separated words instead of camel-case, on the grounds that it's easier to read once there are more than a few words. So constructor_should_throw_exception_for_illegal_number_of_games().
 
Tim Cooke
Marshal
Posts: 4051
239
Clojure IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The likes of the Spock testing framework, for which tests are written in Groovy, take this one step further even and allow you to write an actual String for the test method:
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ali Gordon wrote:...the author encourages us to use descriptive method names like
constructorShouldThrowExceptionForIllegalNbOfGames(int illegalNbOfGames)...

Just an observation, but if you've already gone to the trouble to type a name that big, why not just bite the bullet and call it

constructorShouldThrowExceptionForIllegalNumberOfGames(...) ?

But apart from that, I agree with the others.

Winston
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Cooke wrote:The likes of the Spock testing framework, for which tests are written in Groovy, take this one step further even and allow you to write an actual String for the test method:


Similarly the Scala Test framework also goes a step further and allows us to write test names like:


 
Ali Gordon
Ranch Hand
Posts: 182
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:I like the long method names. Comments tend to get out of sync. Ugly is in the eyes of the reader.


Yes, but after a certain number of chars, it gets difficult to read the method name because of the camel case.
 
Ali Gordon
Ranch Hand
Posts: 182
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Cooke wrote:An advantage of using descriptive test method names is observed when a test fails. Your CI server sends you an email with the following:
.....................test report so is not as useful as you'd think.


Tim cooke, +1 for the continuous integration server example. Thanks. Maybe I'll use underscores as word separators in method names instead of using camel case. Camel case is a pain to read when method names are very long.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My teams use a variation of Neal Ford's convention for test names.

Rules of thumb:

1. Use _ to separate words and don't add "test" to the name

@Test public void can_instantiate_with_just_name()
@Test public void can_instantiate_with_both_name_and_address()

2. Use the annotation to document the expected exception that will be thrown

@Test(expected = EmptyStackException.class)
public void cannot_pop_when_empty()


3. If you must include a method name, use the actual method name.

@Test public void isValid_depends_on_both_foo_and_bar()
@Test public void equals_is_transitive()
@Test public void toString_includes_address()


Note: Must be diligent with test names that include method names because they can get out of synch with the production code if you do refactor-Rename. You have to remember to change the test method names to reflect the new method name.

In the case of your test, we would probably have:

@Test(expected = IllegalArgumentException.class)
public void cannot_instantiate_with_illegal_number_of_games()


// refactored to be more specific:
@Test(expected = IllegalArgumentException.class)
public void cannot_instantiate_with_fewer_than_1_game()

@Test(expected = IllegalArgumentException.class)
public void cannot_instantiate_with_more_than_10_games()
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And in case you're wondering, Neal Ford says that using underscores in test names is fine. It doesn't matter that it's not normal method naming convention. Test methods are exempt from that convention; readability takes precedence over your anal-retentive tendencies when it comes to naming tests. (Well, that last part has a bit of twist that I put in)
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ali Gordon wrote:Maybe I'll use underscores as word separators in method names instead of using camel case. Camel case is a pain to read when method names are very long.

Note that what has been said so far about long method names and underscores apply only to unit test names. I would strongly advise against using underscores in method names in production code; follow standard naming convention and use camel case instead. Also, for production code, you should try to keep method names descriptive but reasonably short. An overly long method name in production code can actually be a code smell that indicates your method does too much. A method should have a single responsibility and if you can't give it a name that succinctly states that responsibility then your method is probably doing too much. This is usually the case if your method name includes "and" in it or has multiple verbs.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!