Sample Java Program and codes for TestCase

[Viji be]

Hello

Can anyone give send me a sample Java Program (like addition of two numbers ) and TestCase codes(JUnit) to test in JUnit?

[Lasse Koskela]

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
}
 
public class CalculatorTest extends junit.framework.TestCase {
 
    public void testAddingTwoPositiveIntegers() throws Exception {
        int expected = 11;
        int actual = new Calculator().add(4, 7);
        assertEquals(expected, actual);
    }
 
    public void testAddingTwoNegativeIntegers() throws Exception {
        int expected = -11;
        int actual = new Calculator().add(-4, -7);
        assertEquals(expected, actual);
    }
 
    public void testAddingNegativeIntegerToPositiveInteger() throws Exception {
        int expected = -3;
        int actual = new Calculator().add(4, -7);
        assertEquals(expected, actual);
    }
}

[Jeanne Boyarsky]

Lasse,
Two questions based on this example. Just trying to figure out whether these are intentional design decisions or something you typed for the sake of example.

1) Do you prefer instantiating objects (like Calculator) inline or in the setup?
2) Do you find value in using the assertEquals(string, int, int) signature? I've seen it listed as a best practice, but there doesn't seem to be any value if there is only one assert in the method. (If there is more than one assert, I understand why it is useful.)

[Lasse Koskela]

Originally posted by Jeanne Boyarsky:
1) Do you prefer instantiating objects (like Calculator) inline or in the setup?

I was avoiding the use of setUp() in favor of less new stuff to learn for a beginner. Indeed, I often write test classes which don't have anything else than assert*() in the test methods and with all the setup and execution performed in the setUp(). Although I guess I leave the execution part into the test methods themselves most of the time.

Originally posted by Jeanne Boyarsky:
2) Do you find value in using the assertEquals(string, int, int) signature? I've seen it listed as a best practice, but there doesn't seem to be any value if there is only one assert in the method. (If there is more than one assert, I understand why it is useful.)

I do use the overloaded "string" versions of assert methods every now and then, mostly in those situations when the statement itself is a bit cryptic and I feel the use of the "description" argument will be prettier than splitting the assertion statement itself into temporary variables or something like that.

One specific situation where I use the assert*(String, ...) versions is with some sort of data-driven tests where I'm looping over an array, comparing each element to something else, etc.

[kri shan]

Hi Lasse, i never used junit..what is the disadvantage of using junit?

[Lasse Koskela]

Originally posted by kri shan:
what is the disadvantage of using junit?

I don't know. I haven't figured out one yet.

Having said that, there are of course some things about JUnit that are not quite as good as they could be but those are minor issues, really. Besides, there really is not that many alternatives for JUnit. The only one I'm aware of that could be considered a real alternative would be TestNG but it's not too commonly used at this point -- you'll have much more community support available if you stick to JUnit. In the future, TestNG might very well become the successor for JUnit as it is more feature rich than JUnit and JUnit is not being developed anymore (as far as I know).

[Jeanne Boyarsky]

Thanks Lasse!

Kri, There aren't really any disadvantages to junit. You'd be writing the tests in some other form anyway, right?