Jump to content
  • Advertisement
Sign in to follow this  
jjd

[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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
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.
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!