Can you look at these simple JUnit tests

[themoffster]

I looked at JUnit before, but I never really used it that often and now I'm trying to refresh my memory.


public class Vehicle
{
protected int noPassengers;
protected String regNo;

public Vehicle(int p, String r)
{
noPassengers = p;
regNo = r;
}

public int getSize()
{
return 1;
}

public String getRegNo()
{
return regNo;
}

public int getNoPass()
{
return noPassengers;
}
}



import junit.framework.TestCase;

public class VehicleTest extends TestCase
{
private Vehicle v1, v2;

public void setUp()
{
v1 = new Vehicle(2, "A-reg");
v2 = new Vehicle(1, "B-rag");
}

public void testGetNoPass()
{
assertFalse(v1.equals(v2));
}

public void testGetRegNo()
{
assertFalse(v1.equals(v2));
}

public void testGetSize()
{
//assertTrue(v1.equals(v2));
assertFalse(v1.equals(null));
}
}


Now a couple of points:
At present all the assertions run OK, but why does the commented out one in the last method result in a failure? I'm curious as the method should only return one integer, which doesn't change.
Secondly, I believe that it is bad practice to call the method that you are testing in the method (i.e. calling v1.getSize() in the testGetSize() method) - is this correct? Also, what other assertions could I write? I'm struggling to think of any as I'm trying not to call the methods that I'm testing.

Thanks.

[khp]

I'am not much of a JUnit bofh, so I suppose I could be wrong. But I would like to raise a couple of points.

but why does the commented out one in the last method result in a failure?

Can we aggree that it's quite resonable to expect v1.equals(v2) to be false, you assert this in the testGetNoPass and testGetRegNo methods, and it seems very reasonable to expect it to be so. In the testGetSize method you try to assert it to be true (ie. v1.equals(v2)), and you are surprised this assertion fails ?.


I'm curious as the method should only return one integer, which doesn't change.


What metod, getSize ?, But none of your asserts involves getSize.


Secondly, I believe that it is bad practice to call the method that you are testing in the method (i.e. calling v1.getSize() in the testGetSize() method) - is this correct?


Again I'am no JUnit bofh, but that seems completely absurd to me. How can you possibly claim to have tested a method, without calling it ?. Someone might delete or rename your methods, and your assertions would fail to register this.


Also, what other assertions could I write? I'm struggling to think of any as I'm trying not to call the methods that I'm testing.


Your class is not very big, and you havent provided any explanations for the purpose of the class. So it's difficult to come up with any interresting assertions.

The testgetRegNo would seem more relavant if it asserted that two different cars did not return the same RegNo, and the same car returns the same RegNo

assertFalse(v1.getRegNo().equals(v2.getRegNo()));
assertTrue(v1.getRegNo().equals(v1.getRegNo()));

And assuming that size refers to the number of passenges a vehicle can carry it might also be relevant to assert that there are no more passengers in the car than the size allows.

assertFalse(v1.getSize()<v1.getNoPass())

[themoffster]

I'am not much of a JUnit bofh, so I suppose I could be wrong. But I would like to raise a couple of points.



Can we aggree that it's quite resonable to expect v1.equals(v2) to be false, you assert this in the testGetNoPass and testGetRegNo methods, and it seems very reasonable to expect it to be so. In the testGetSize method you try to assert it to be true (ie. v1.equals(v2)), and you are surprised this assertion fails ?.
This is just a typo, can't believe that I missed it.
Again I'am no JUnit bofh, but that seems completely absurd to me. How can you possibly claim to have tested a method, without calling it ?. Someone might delete or rename your methods, are your assertions would fail to register this.
Yeah, taht's what I was thinking, but wasn't sure.

The testgetRegNo would seem more relavant if it asserted that two different cars did not return the same RegNo, and the same car returns the same RegNo

assertFalse(v1.getRegNo().equals(v2.getRegNo()));
assertTrue(v1.getRegNo().equals(v1.getRegNo()));

And assuming that size refers to the number of passenges a vehicle can carry it might also be relevant to assert that there are no more passengers in the car than the size allows.

assertFalse(v1.getSize()<v1.getNoPass())
Thanks.

Good reply - it's appreciated!

[dlorde]

A JUnit test method is simply supposed to test that the corresponding method of the class under test does exactly what it is supposed to do.

All the test methods you posted are testing whether the object instances, created with different arguments, are equal. The result of this comparison will always be the same, and has nothing to do with the methods that are being tested. What's the point?

In any case, there's little point comparing the values returned from two instances with each other - you just need to establish that the value returned from a single method call is the value that is supposed to be returned (in this case, the value that was passed in). So compare the return value with the value passed to the constructor.

This is the kind of thing I'd expect to see:public void testGetNoPass() {

// Various extreme and normal test values
int[] passengers { -1, 0, 1, 50, 1000 };

Vehicle v;

// Test that the method returns the correct number of passengers each time
for (int i = 0; i < passengers.length; i++) {

// create with a test value
v = getVehicle(passengers[ i ], "Test Vehicle");

// check that what you get out is what you passed in
assertEquals(passengers[ i ], v.getNoPass());

}
}

// Utility method to create a vehicle and check the construction
private Vehicle getVehicle(int noPass, String regNo) {

return new Vehicle(noPass, regNo);

// if constructor throws exceptions, handle them here
}In your Vehicle example, there are no checks for invalid values, such as trying to set a negative number of passengers, but in any real class, your JUnit tests would also be testing for correct handling of these sorts of things (usually those tests would be done by the constructor test method).

A more realistic, practical class is really needed to show the full benefit of JUnit tests.

Optimism is an occupational hazard of programming: testing is the treatment...
K. Beck