JUnit and multiple classes

[Tavia Young]

Hi Everyone,

I was curious as to what your thoughts are on the following scenario with regards to unit testing. If an Article class calls upon a method in a customized Utility class, would it still be good practice to write a test
within ArticleTest to verify that the customized Utility method was properly executed? Or, would it be best to write separate test cases (e.g. ArticleTest and CustomUtilityTest for each class)? I am leaning towards the latter as it is conventional to have one TestCase per Java class. Thanks much for your help!

Tavia

[Junilu Lacar]

I would say that you're leaning in the right direction. I'm always suspicious of "Utility"-type classes and since you're debating whether to test it together with the other class, there could be a hint of a code smell there. Could it be that the code in your utility class is not really a "utility" method. Does it suffer from feature envy?

[Tavia Young]

Thanks for your reply, Junilu. I think it makes good sense to test the customized Utility class with a separate TestCase; however, could you elaborate a bit more on "feature envy"?

I'm also curious if there is a case where you would want to test two classes together? If so, how would one go about it?

Thanks again!

[Lasse Koskela]

Originally posted by Tavia Young:
could you elaborate a bit more on "feature envy"?

Feature Envy means that a class A is using class B's features so much that it might make sense to move those features into class A.

[Junilu Lacar]

Originally posted by Lasse Koskela:

Feature Envy means that a class A is using class B's features so much that it might make sense to move those features into class A.

Or move the "envious code" from class A to class B.

I'll try to post a good example later.

[Lasse Koskela]

Originally posted by Junilu Lacar:
Or move the "envious code" from class A to class B.

Doh [slaps forehead]

Yes, obviously that is the other option.

[Tavia Young]

Thanks, Lasse and Junilu. If you could post an example, that would be great. =)

[Lasse Koskela]

One example of Feature Envy coming up...

Here's a class named Square, which represents (drum roll, please) a square:

import java.awt.Point;
 
public class Square {
 
private Point leftTop;
private Point leftBottom;
private Point rightTop;
private Point rightBottom;
 
public Square(Point leftTop, Point rightBottom) {
this.leftTop = new Point(leftTop);
this.rightBottom = new Point(rightBottom);
this.leftBottom = new Point(leftTop.x, rightBottom.y);
this.rightTop = new Point(rightBottom.x, leftTop.y);
}
 
public Point getLeftTop() {
return leftTop;
}
 
public Point getLeftBottom() {
return leftBottom;
}
 
public Point getRightTop() {
return rightTop;
}
 
public Point getRightBottom() {
return rightBottom;
}
}

Now, here's a class that uses the Square class above in a manner that smells like Feature Envy:

import java.awt.Point;
 
public class EnvyingClass {
 
public Point calculateCenter(Square square) {
double x = (square.getLeftBottom().x + square.getRightBottom().x) / 2;
double y = (square.getLeftTop().y + square.getLeftBottom().y) / 2;
Point center = new Point();
center.setLocation(x, y);
return center;
}

}

The use of multiple getter methods on the object being passed to a method often indicates that it would make sense to use the Move Method refactoring. In our example, that would mean moving the calculateCenter(Square square) method into the Square class:

package saloon.refactoring.featureenvy;
 
import java.awt.Point;
 
public class Square {
 
...
 
// notice the missing method argument
public Point calculateCenter() {
double x = (getLeftBottom().x + getRightBottom().x) / 2;
double y = (getLeftTop().y + getLeftBottom().y) / 2;
Point center = new Point();
center.setLocation(x, y);
return center;
}
}

[Tavia Young]

Thanks very much, Lasse. =)

On an related (or unrelated) note, how would one go about testing a class that is declared as an Interface? Thanks again!

[Jeanne Boyarsky]

Tavia,
An interface doesn't have any implementation code (as it is just a declaration of signatures) so there isn't anything to test. You would test the code that uses the interface the same way as "regular" code.

[Ilja Preuss]

What you *can* do for the interface is write tests for the contract all implementations should obey. See http://c2.com/cgi/wiki?AbstractTestCases

[Tavia Young]

Originally posted by Jeanne Boyarsky:
You would test the code that uses the interface the same way as "regular" code.

Thanks very much, Jeanne & Ilja.

I realize that I should really be testing the code which makes use of the Interface, as Jeanne mentioned above. For example, if I were to test the Struts FormFile, how would one declare this Interface (i.e. The code I would like to test has some operations performed on a FormFile object.)?

Thanks again!

[Lasse Koskela]

Originally posted by Tavia Young:
For example, if I were to test the Struts FormFile, how would one declare this Interface (i.e. The code I would like to test has some operations performed on a FormFile object.)?

When the code under test uses an interface, you generally either
1) create a static mock implementation of that interface, geared for testing only, or
2) use a mock implementation of that interface from an existing library such as mockobjects.com (if the interface is a standard java.* or javax.* interface), or
3) use a dynamic mock object library such as EasyMock or JMock to create a mock implementation of the interface in your test code

[Tavia Young]

Thanks a bunch, Lasse. JMock seems like an interesting tool to use. Will investigate some more...

[Ilja Preuss]

Originally posted by Tavia Young:
Thanks a bunch, Lasse. JMock seems like an interesting tool to use. Will investigate some more...

Personally, I prefer EasyMock over JMock - it's a little bit less flexible (though still flexible enough for 80% of the time) and does use actual method calls on the mock to "program" expectations, so that it goes smoother with automated refactorings. That is, if you rename a method on the Interface you mock, the JMock test will likely fail, whereas the EasyMock test will simply get refactored along.

EasyMock also is a little bit less verbose in most cases, so it seems to me.

[Lasse Koskela]

I fully agree with Ilja regarding EasyMock vs JMock. In addition, EasyMock actually has documentation which cannot be said about JMock...

[Tavia Young]

You guy are fabulous! I agree - there doesn't seem to be much documentation available for JMock.

What are your views on units tests for reading and writing files (i.e. the classes in java.io.*)? Thanks again! =)

[Lasse Koskela]

Originally posted by Tavia Young:
What are your views on units tests for reading and writing files (i.e. the classes in java.io.*)?

Don't test them. You have to take for granted that the J2SE core classes have been implemented correctly...

Then again, if you meant testing your own class such as

public class MyIoUtils {
 
    public static String readFileAsString(File file) {
        ... // reading the file using java.io.*
    }
 
}

which uses java.io.*, then I would probably write unit tests for that code.

[Tavia Young]

That makes good sense, Lasse.

In reference to the above messages re Interfaces and Easy Mock/JMock, does it make more sense to test the struts FormFile class or the implementation of the class, CommonsFormFile? I always get so confused when it comes to java IO and file uploads!

[Lasse Koskela]

Originally posted by Tavia Young:
does it make more sense to test the struts FormFile class or the implementation of the class, CommonsFormFile?

Always use the level of abstraction your code under test uses. If you have a method like
public String doSomethingToFormFile(FormFile ff)
you use EasyMock/JMock to generate a mock object for FormFile, not for some specific implementation of FormFile.

[Ilja Preuss]

Originally posted by Tavia Young:
What are your views on units tests for reading and writing files (i.e. the classes in java.io.*)? Thanks again! =)

Actual file access is rather slow and unreliable. I typically prefer to code against streams, readers or writers instead, and use the appropriate in-memory implementations (ByteArray* or String*) for testing.