toString


toString

You have seen how you can send the toString message to a StringBuilder object in order to extract its contents as a String.

The toString method is one of the few methods that the Java designers chose to define in java.lang.Object. Its primary purpose is to return a printable (String) representation of an object. You could use this printable representation as part of an end-user application, but don't. The toString method is more useful for developers, to help in debugging or deciphering a JUnit message.

You want objects of the Course class to display a useful string when you print them out in a JUnit error message. One way would be to extract its elements individually and produce a concatenated string. Another way is to use the toString method.

 public void testToString() {    Course course = new Course("ENGL", "301");    assertEquals("ENGL 301", course.toString()); } 

Since toString is inherited from Object, you get a default implementation that fails the test:

 expected: <ENGL 301> but was: <studentinfo.Course@53742e9> 

This is the implementation that passes the test:

 @Override public String toString() {    return department + " " + number; } 

Many IDEs will display objects in watch or inspection windows by sending them the toString message. JUnit uses toString to display an appropriate message upon failure of an assertEquals method. If you code:

 assertEquals(course, new Course("SPAN", "420")); 

then JUnit will now display the following ComparisonFailure message:

 expected: <ENGL 301> but was: <SPAN 420> 

You can concatenate an object to a String by using the + operator. Java sends the toString message to the object in order to "convert" it to a String object. For example:

 assertEquals("Course: ENGL 301", "Course: " + course); 

The default implementation of toString is rarely useful. You will probably want to supply a more useful version in most of your subclasses. If you only use the toString implementation for the purpose of debugging or understanding code, writing a test is not necessary.

In fact, toString's definition is often volatile. It depends upon what a developer wants to see as a summary string at a given time. Creating an unnecessary toString test means that you have made the production class a little harder to change.

One of the main reason you write tests is to allow you to change code with impunity, without fear. For each test that is missing, your confidence in modifying code diminishes. Writing tests enables change. The irony is that the more tests you have, the more time-consuming it will be to make changes.

You should never use the difficulty of maintaining tests as an excuse to not write tests. But you should also not write tests for things that are unnecessary to test. You should also code your tests so that they are as resistant as possible to change. Finding the right balance is a matter of experience and good judgment.

Ultimately, it's your call. My usual recommendation is to start out with more tests than necessary. Cut back only when they become a problem that you can't fix through other means.



Agile Java. Crafting Code with Test-Driven Development
Agile Javaв„ў: Crafting Code with Test-Driven Development
ISBN: 0131482394
EAN: 2147483647
Year: 2003
Pages: 391
Authors: Jeff Langr

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net