Page 1 of 2 12 LastLast
Results 1 to 20 of 30
  1. #1
    acmohan is offline Member
    Join Date
    Jul 2011
    Posts
    26
    Rep Power
    0

    Default Could any help me in JUNIT

    hi all, i am learning junit test cases. I have some scenario ,can any 1 help on this
    sample code is here
    Java Code:
    public string getcust(Long Id){
    
    List<Long> lst=getlist(id);
    JSONArray jAy = new JSONArray();
    for(Long lst1:lst){
    JSONObject jsobj=new JSONObject();
    jstobj.put("1:",lst1.getid());
    jstobj.put("2:",lst1.getid());
    jAy.put(jstobj);
    }
    return jAy.tostring();
    }
    can any help me to write junit test case for this scenario(getcust method) .It wil be the great help.

    thanks in advance.

  2. #2
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Your method is not very testable because of the
    Java Code:
    List<Long> lst=getlist(id);
    call. The method is not well focused.
    You should have a separate test case for the getlist(id) method because it's already a separate method which can be called from other other methods.
    Change your getcust method to
    Java Code:
    public String toJSONString(List<Long> values){
    It makes sense to give it a name that is related to what it's actually doing (also read up on naming conventions).
    Your test case is now easy as you can set up may types of List<Long> (empty, one value, mutiple values) with expected results for the JSON String and assert that you are getting the right result.
    This is why most people prefer doing the test cases first because they force you to write testable code which is usually better to mantain.

    P.S The code
    Java Code:
    jstobj.put("1:",lst1.getid());
    jstobj.put("2:",lst1.getid());
    doesn't make much sense as it sets the same value against different names

  3. #3
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    If getlist() is private, though (ie some utility method that is used throughout the code) then the above method is OK.
    Otherwise you'd be exposing that List to the outside world which may not be desirable (though we have no idea what's actually going on here).
    So getlist is not something to be tested, except indirectly.

    How this above method is tested is therefore down to how getlist works.

  4. #4
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Even if getlist is private, it must be tested independently.
    Private methods should be tested too (especially if they are utility like you're saying ).
    If that is the case (unlikely) then there should be a
    Java Code:
    private String toJSONString(List<Long> values)
    and
    Java Code:
    private List<Long> getValuesList(Long id)
    and all of them should have their own test cases.

  5. #5
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    Not via JUnit they aren't.
    JUnit tests the exposed methods of your interface (which is what you ought to be testing).
    Who cares how the internal methods are broken up.

    Indeed, unit testing tests the unit (the class) that its exposed methods function as defined.
    If getlist() isn't exposed then it's not up for testing.

  6. #6
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    If you don't test your privates, how do you know they won't break?
    There are two reasons for writing test cases
    1.) Guarantee that client behaviour is as expected (testing exposed objects is sufficient for this). This gives business satisfaction.
    2.) Protecting against bad code changes. Code changes includes changes to private methods and it is possible for private methods to have compensating errors that make public method tests pass. A completely robust application tests every line of code in the application and this gives developer satisfaction.


    See here for some approaches:Testing Private Methods with JUnit and SuiteRunner
    Last edited by r035198x; 07-14-2011 at 11:11 AM. Reason: compensating errors that make public method tests pass

  7. #7
    acmohan is offline Member
    Join Date
    Jul 2011
    Posts
    26
    Rep Power
    0

    Default

    i am sorry i am getting confused.
    so if internal method which is called is private ,we should not test it ?.
    Don't test private methods.
    .

    if not then how to do it?.can i get links r hints where i can get in detail about this?.

  8. #8
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    Quote Originally Posted by r035198x View Post
    If you don't test your privates, how do you know they won't break?
    There are two reasons for writing test cases
    1.) Guarantee that client behaviour is as expected (testing exposed objects is sufficient for this). This gives business satisfaction.
    2.) Protecting against bad code changes. Code changes includes changes to private methods and it is possible for private methods to have compensating errors that make public method tests pass. A completely robust application tests every line of code in the application and this gives developer satisfaction.


    See here for some approaches:Testing Private Methods with JUnit and SuiteRunner
    And?
    Your unit testing is to test the results from external calls.
    It's almost blackbox in that respect.
    When I write my tests (based on my interfaces defined at the start of development) I don't know what private methods I'm going to write.

    Those methods (if they're used) are tested via testing the exposed interface. In other words, tested in the way they are going to be used.
    No point me writing specific tests for them.

    If I add a new exposed method to my interface then I write a test that shows what's expected from a call to that method.

    I've never written a test for a private method because it's utterly irrelevant.

  9. #9
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Quote Originally Posted by Tolls View Post
    And?
    Your unit testing is to test the results from external calls.
    .
    Read my reply above again where I stated the two reasons for testing. Testing is not just about making clients happy. It's also about making a robust system.
    Quote Originally Posted by Tolls View Post
    When I write my tests (based on my interfaces defined at the start of development) I don't know what private methods I'm going to write.

    Those methods (if they're used) are tested via testing the exposed interface. In other words, tested in the way they are going to be used.
    No point me writing specific tests for them.

    If I add a new exposed method to my interface then I write a test that shows what's expected from a call to that method.

    I've never written a test for a private method because it's utterly irrelevant.
    That's because you've never done test driven development.

  10. #10
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    I did read your reply, and I'm not talking about making clients happy.
    A robust system consists of methods that do what they're asked, provide consistent results, and make sub calls as expected.

    I can only think of problems with monster classes, and that's got nothing to do with unit testing.

    As for TTD, I have and do. TTD is premised on building tests defined at the interface level. By its very nature it is about providing a test that tests a new piece of functionality (ie Use Case). Private methods are not a Use Case by their very nature.

  11. #11
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    Tolls and r035198x both have part of the truth.
    Tolls has, because a programmer must feel free "to tamper with the privates", and it is the unit's behaviour that counts.
    But r035198x (I need a JUnit-test for this name) is right (more i.m.h.o) that there is no principal boundary to chopping up code in testable units, including private methods.
    Otherwise you could also see the program as a black box, and only just test that.
    A book I have here (Next Generation Java Testing, 2008, on TestNG and JUnit) advises to relax the visibility and make methods package-protected, or use reflexion, using a setAccesible flag to bypass a security check. Both have disadvantages (tests must then be in the package / you need intimate knowledge of (changable!) methodnames, used in the testcode as Strings). I myself use a kind of convention making public testMethods with names as initControllerJUNIT() and don't use them in regular code.
    No bug ever had to calculate its fitnessfunction.

  12. #12
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    Quote Originally Posted by Jodokus View Post
    Otherwise you could also see the program as a black box, and only just test that.
    I disagree.
    In order to unit test you need units...if you make those units too big to test then that's a design problem.
    I hold that if you find yoursself having to test private methods then it's quite likely your classes are too large.

  13. #13
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Quote Originally Posted by Tolls View Post
    I did read your reply, and I'm not talking about making clients happy...
    The reason why I don't you'd read it is because
    1.) I asked how you ensure that your privates don't break without test cases and you didn't answer that.
    2.) I mentioned that two private calls can have compensating errors which can make public tests pass and you offered to solution to that.
    You also repeat the idea that unit tests are only there for public interfaces.

    I also suspect that you didn't read the link I posted above, Testing Private Methods with JUnit and SuiteRunner which gives more reasons why one would test private methods and the approaches to use.

    Quote Originally Posted by Tolls View Post
    A robust system consists of methods that do what they're asked, provide consistent results, and make sub calls as expected.
    Look up robustness to see how none of that have to do with it and how it's about a system that does not collapse under changes (to any of its parts).
    Quote Originally Posted by Tolls View Post
    TTD is premised on building tests defined at the interface level.By its very nature it is about providing a test that tests a new piece of functionality (ie Use Case). Private methods are not a Use Case by their very nature.
    Private methods are use cases for the public methods.
    Do yourself a favour and read at least just the wiki entry for TDD (the Code Visibility section).

  14. #14
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    Quote Originally Posted by r035198x View Post
    The reason why I don't you'd read it is because
    1.) I asked how you ensure that your privates don't break without test cases and you didn't answer that.
    2.) I mentioned that two private calls can have compensating errors which can make public tests pass and you offered to solution to that.
    You also repeat the idea that unit tests are only there for public interfaces.
    1. You don't. Because you test what the class does. All you need to know is that it interacts with who it should interact with, and that its final state matches what it should do at the end of its processing.

    2. Examples? Because again, outside of a badly designed class (which is what coding standards and code reviews are for) that should never be the case.

    Quote Originally Posted by r035198x View Post
    I also suspect that you didn't read the link I posted above, Testing Private Methods with JUnit and SuiteRunner which gives more reasons why one would test private methods and the approaches to use.
    I did read the link, and I don't agree with him re:private testing. I write code similar to the way the author does, by the sounds of it, with very short methods callign equally short private methods to break down a single flow problem. I do not see the need to test those individual private methods since they are all part of the solution to the overall problem or use case. They do not, themselves, consitute a use case outside of their place in the grand scheme. Testing them formally is a pointless exercise.

    Quote Originally Posted by r035198x View Post
    Look up robustness to see how none of that have to do with it and how it's about a system that does not collapse under changes (to any of its parts).
    And a system with a suite of standard unit tests will show that. Unless you have some very strange code.

    Quote Originally Posted by r035198x View Post
    Private methods are use cases for the public methods.
    Do yourself a favour and read at least just the wiki entry for TDD (the Code Visibility section).
    "There is some debate among practitioners of TDD, documented in their blogs and other writings, as to whether it is wise to test private and protected methods and data anyway."

    And I think you can see where I stand on this.

  15. #15
    acmohan is offline Member
    Join Date
    Jul 2011
    Posts
    26
    Rep Power
    0

    Default

    Ok thanks for you suggestions. pls someone clear my doubt.
    if i mock inner method then outer method wont give the response as expected so hw to write a test case for it. below s wat i mean
    Java Code:
    public string methodname(parameters){
    .
    .
    .
    List<long> lst=somemethod();
    .
    .
    .
    return string;
    }
    part test case
    Java Code:
     when(packagename.somemethod()).thenreturn(list);
    
    string s=methodname(parameters);
    i am confused can any1 can give outline of test case for my scenario. help me out in this ,i have struck here from long time.

  16. #16
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    In order to unit test you need units...if you make those units too big to test then that's a design problem.
    I hold that if you find yoursself having to test private methods then it's quite likely your classes are too large.
    I agree in so far as it is wise to avoid the need of testing privates. And mostly I make pretty small classes with one well defined and testable mission.
    But also when I depart from this guideline, it is not the task of the testing-tool to force me not to test something I have doubts about, or want to make sure it's not broken somewhere in the future (and then where it's broken). I have f.i. some library that works very well, is very hard to understand (also by me, the maker), and difficult to refacter. I'm sure I'll do this refactoring in the future, but in the meantime I have testingcode to help me trust it, (and show me after some time how it was supposed to work).
    Last edited by Jodokus; 07-14-2011 at 04:33 PM.
    No bug ever had to calculate its fitnessfunction.

  17. #17
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Quote Originally Posted by acmohan View Post
    i am confused can any1 can give outline of test case for my scenario. help me out in this ,i have struck here from long time.
    Is some somemethod() a private method? If not then read the first reply again.
    If it is private but you realize that you need to test it (unlike other people ) then you can pull its functionality into a separate class and make it public there allowing you to test it. You can protect access to it by giving it package access.

  18. #18
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    @Tolls, when you write a private method, how do you tell future developers what the intention of that method was supposed to be? How do you ensure that your intentions for that private method are indeed being realised by your implementation?

  19. #19
    Jodokus's Avatar
    Jodokus is offline Senior Member
    Join Date
    Jan 2011
    Location
    Amsterdam, the Netherlands
    Posts
    230
    Rep Power
    4

    Default

    I would do it like this, but I pollute my class a bit with testingcode.
    (I understood this has nothing to do with private/public ?)
    Java Code:
    package forumTest;
    import java.util.ArrayList;
    import java.util.List;
    
    public class ProblemClass {
    	private List mockList = new ArrayList<Long> ();
    	private boolean testSituation = false;
    	
    	public String methodname( int parameter1 ){
    		String result = "part of expected";
    		List<Long> lst;
    		if( ! testSituation ){
    			lst = SomeOtherClass.someMethod();
    		}else{ lst = mockList; }
    		return result;
    	}
    	public void forTestJUNIT( List<Long> testLst ){
    		mockList = testLst;
    		testSituation = true;
    	}
    }
    
    class SomeOtherClass{
    	public static List<Long> someMethod(){
    		List<Long> result = new ArrayList<Long> ();
    		result.add( 876866L );
    		return result;
    	}
    }
    Last edited by Jodokus; 07-14-2011 at 04:38 PM. Reason: formatting
    No bug ever had to calculate its fitnessfunction.

  20. #20
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,091
    Rep Power
    20

    Default

    Quote Originally Posted by r035198x View Post
    @Tolls, when you write a private method, how do you tell future developers what the intention of that method was supposed to be? How do you ensure that your intentions for that private method are indeed being realised by your implementation?
    Documentation within the code, pure and simple.
    Much of it is only a handful of lines long, so obfuscation is a rarity.

    Again, though, if that code is changed in such a way as to react "strangely" (in order to fit in with some later use of the method, say), then that will be reflected in failing test cases.

Page 1 of 2 12 LastLast

Similar Threads

  1. integrating JUnit with EJB
    By aagarw04 in forum Enterprise JavaBeans (EJB)
    Replies: 0
    Last Post: 03-10-2011, 12:55 PM
  2. JUnit
    By cka in forum Eclipse
    Replies: 3
    Last Post: 07-27-2010, 04:14 PM
  3. JUnit Test Help!
    By pharo in forum New To Java
    Replies: 0
    Last Post: 04-10-2009, 05:15 PM
  4. Junit
    By Azndaddy in forum New To Java
    Replies: 6
    Last Post: 06-15-2008, 06:47 AM
  5. TRying to use jUnit for Tesing
    By sandor in forum New To Java
    Replies: 3
    Last Post: 04-18-2007, 11:17 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •