JUnit Tests - what do i test?

If I have a basic accessor method that r开发者_StackOverflow中文版eturns an ArrayList

What exactly would i test for it? I am very inexperienced when it comes to testing.

---

That depends on how you expect the method to behave. For example: If someone has called the method and changed the list that was retrieved, do you want those changes to show up the next time the getter is called? Either way, test that behaviour. What does the getter return when the list would be empty? Null or an empty list? This should also be tested.

---

Typically writing explicit Junit tests for accessors is usually a little overkill (what are you testing? return foo;). Using a code coverage tool such as clover can help you target your testing efforts at your most complicated code first.

---

Interessting question for you:

How much should a unit test "test"

How to use Junit and Hibernate usefully

What should not be unit tested

Edit:

Added some of my favorite Questions here on Stackoverflow regarding JUnit and Unit Testing.

---

Always keeps in mind that test code is also code and for every 1,000 lines of code, you produce at least 4 bugs. So test what doesn't work and don't write tests for something that can't possibly break (like code generated by your IDE). If it does break, write a test :)

---

In general unit tests should test that your method does what it states it should do.

If your method returns an arraylist your basic test is to assert that an arraylist is indeed returned when it is called.

The next level of detail in the test is to check is the arraylist constructed correctly? Have the values you expect in it been filled correctly? If it's supposed to be an empty list, is that the case?

Now you have your "sunny day" case (i.e the method works under normal conditions) you should add some negative (or "rainy day") conditions if appropriate. If the method accepts a length for the array, what if you pass in a negative number or a int.Max etc.

As stated in another answer, this is probably overkill for a simple accessor, but the principles apply to any unit tests you need to write.

---

Depends on your requirements. You might test:

1. If the return value is not null
2. If the returned collection is not empty
3. If the returned collection is modifiable/unmodifiable
4. If the returned collection is sorted
5. If the returned collection contains all expected values
6. If the accessor method does not throw a runtime exception

But, as I said, it depends on the requirements, it depends on the 'kind' of collection you expect when you call the accessor. Maybe you allow setting the list to null but create an empty list. The the test could make sure that you really get an empty list when you set the list to null.

Hope it helps to give you an idea!