CODEWITHSUNDEEP
javajunit
Gaurav
Gaurav

Reputation: 11

Junit Test Case

Hi I am new to writing JUnit test case. Can anybody help me with this methods?

private boolean validateDate(Date date, String datesInCsv) {
        boolean dateAlreadyExist= false;
        final String[] dateVal = datesInCsv.split(",");
        List<Date> allDates = new ArrayList<Date>();


        for (final String stringDate : dateVal ) {
            allDates .add(DateUtil.parseDate(stringDate ,"MM/dd/yyyy"));
        }
        if (allDates .contains(date)) {
            dateAlreadyExist= true;
        }
        return dateAlreadyExist;
    }

How to start and what should be kept in mind before writing test cases for these kind of methods?

Upvotes: 0

Views: 2593

Answers (3)

Paul McKenzie
Paul McKenzie

Reputation: 20096

A testing purist would answer "how to start" by saying start with the test, not the implementation. But you're past that point already as you have your method.

And cjstheno is correct, testing private methods is, um, strange.

So I usually start with tests around bad inputs

@Test(expected = IllegalArgumentException.class)
public void nullDateIsBadInput() {
    yourclass.validateDate(null, "01/01/2000");
}

And then I test the main thrust of the method

@Test
public void janFirstIsInInput() {
    Assert.assertTrue("janFirst is in inuputs", 
        yourclass.validateDate(janFirst, "01/01/2000, 01/02/2000");
}

@Test
public void janFirstIsNotInInput() {
    Assert.assertFalse("janFirst is not in inputs", 
        yourclass.validateDate(janFirst, "04/01/2000, 01/02/2000");
}

Don't forget to put the optional message into assert call, it makes it easier later on when you come back to the code.

And finally don't forget to refactor your code (and your tests!) once you have got a test working, e.g. return the value of allDates .contains(date) rather than store it in the redundant variable.

Upvotes: 1

Kevin Welker
Kevin Welker

Reputation: 7937

Starting with @Paul, don't forget to test boundaries around iteration. Since datesInCsv can be multiple dates, test the empty String, a String that represents a single date, and a String that represents multiple dates.

Then there is your expectations around questionable inputs, which gets back to your requirements. This includes things like white-space at the beginning, end, or in-between dates in the string. What about trailing commas? These kinds of questionable things are very important as tests because they serve as a form of documentation of requirements for future developers who may come in later and want to "optimize" things. Remember, the goal of tests is not merely to make sure things are working today, but to also preserve those expectations in executable form so as to ensure they are true tomorrow too.

Upvotes: 0

cjstehno
cjstehno

Reputation: 13984

Generally you dont directly test private methods, but you would get test coverage by testing the methods that call it. There is nothing saying you cannot test it though.

You will need to use reflection (or Groovy) to test it since it is private.

As far as what to test, you will want to test null and other unexpected input values as well as any boundary conditions (really big date, really small, ect). Also in your case you may want to check unexpected date formats.

The Junit web site (and a junit google or Stackoverflow search) can provide you with a lot more thoughts on unit testing.

Hope this helps a little.

Upvotes: 0

Related Questions