# [java] contingent tests in junit

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I'm not very experienced with unit testing and this question might highlight that [smile] I have a class that contains a list of objects. There is an add() method, which puts stuff into the list, and a get() method that... well, gets the stuff from the list. What I don't understand about JUnit is how to create an object for testing so that I can test if the get() method works. I also need to test whether the add() method works... but they seem contingent on one another (i.e. if one doesn't work, you can't really trust the other). So is there are correct way to approach this problem? -Josh

##### Share on other sites
Expose the underlying, tested container by making it protected (package level accessible) and including the tests in the same package. You can then test the add and get methods independently of one another.

as for creating objects, look into a concept called mock objects.

unit testing usually leads to an interface heavy design, specifically for this mock object purpose. this isn't necessarily bad.

##### Share on other sites
It's easier to think about in terms of writing test cases than thinking about testing functions. Your first unit test will probably be just add a single item and see if you get it back. Then add two items and see if you get them both back. Then maybe be wild and test five items. Or a mix of adding and getting. If they all work then chances are both functions work. If they don't, then you get the fun job of debugging. The point is since the functions are designed to be used together, then they should be tested together.

##### Share on other sites
Thanks capn_midnight and SiCrane! It makes more sense now.

-Josh

##### Share on other sites
It's also important to only test one piece of functionallity at a time. You don't want to write 20 tests for 10 or 12 different methods of your class and THEN try to run the tests, fix the bugs, etc. You want to write ONE test, run it, fix it, repeat. Don't forget also, you write tests before you write code.

##### Share on other sites
Quote:
 Original post by capn_midnightExpose the underlying, tested container by making it protected (package level accessible) and including the tests in the same package. You can then test the add and get methods independently of one another.as for creating objects, look into a concept called mock objects.unit testing usually leads to an interface heavy design, specifically for this mock object purpose. this isn't necessarily bad.
If it's already private then it shouldn't be made protected just to test it: use reflection instead.
YourClass yourObject = new YourClass();Field collectionField = YourClass.getDeclaredField("yourPrivateFieldName");collection.setAccessible(true);Collection collection = (Collection)collectionField.get(yourObject);

However, in this circumstance I wouldn't do that.

You're testing that the class behaves as it should, so it doesn't matter what the underlying implementation is as long as when you add() an object, you can get() it. Test that instead of testing the underlying implementation.
edit: i.e. exactly what SiCrane said [smile]...

##### Share on other sites
Generally speaking, I don't like using private anyway. Using protected with a good package structure (should be doing that anyway) offers plenty of protection for the same purposes of private (hiding details from implementors), but allows me greater flexibility in subclassing and eases my testing. If I break my own code by incorrectly using elements that are in protected scope, then I'm a dumbass and it's my own dumb fault. Incidentally, my tests will reveal that to me. But at least I've prevented the naive user of my library from doing the same.

There is also a point at which I decide I'm not going to dumb down my code just because I don't want the lowest common denominator drooling on himself when he does something stupid. A) someone that dumb probably isn't a programmer, and B) if they are, I don't want them using my code anyway. Yes, I'm an elitist bastard, it makes my life exponentially easier.

1. 1
Rutin
22
2. 2
3. 3
4. 4
5. 5

• 9
• 9
• 9
• 14
• 12
• ### Forum Statistics

• Total Topics
633307
• Total Posts
3011288
• ### Who's Online (See full list)

There are no registered users currently online

×