Page 2 of 2 FirstFirst 12
Results 21 to 30 of 30
  1. #21
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    12,086
    Rep Power
    20

    Default

    Quote Originally Posted by Jodokus View Post
    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;
    	}
    }
    If that list is coming from something outside the class being tested then you should be able to mock the thing that is supplying the list.
    You shouldn't need to change your code like that to test it.

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

    Default

    Quote Originally Posted by Tolls View Post
    Documentation within the code, pure and simple...
    So you have no way of validating that what you intended for the private method to do is actually what it is doing because just saying that this method does X won't make it do X.
    It may seem like it's doing X to the one public method that you are going to write test cases for (let's call it M) but new methods added to that class that need to do X will assume full X behaviour and fail. Sure they can write another private X2 method that really does X but the point is your X was buggy and there were no test cases to catch the bug. The problem is not that test cases for M were insufficient because they (rightfully) new nothing about functionality X and only indirectlty tested the parts of X that they needed.
    This is what robustness is all about.

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

    Default

    So long as the exposed method is doing what it should then, by default, the underlying private method is.
    As soon as the underlying private method does not do what it is supposed to do then the test for the exposed method will fail.

    Why is that so hard to understand?

    I honestly am curious as to what it is that this mythical private method is doing such that it can be wrong and yet still produce the correct result.

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

    Default

    If you have not understood the point in my last post above then it's unlikely that me writing more words here is going to help.

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

    Default

    No I do understand.
    However those added methods that call X expecting X to do what they think X should do will fail...as you have said.
    In their test cases.
    Note...new functionality.

    So either X is refactored, X is renamed, or the assumptions behind this new method calling X needs changing.
    None of these require a test case for X since X does what it was intended to do, which is provide functionality for the method I originally wrote it for.

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

    Default

    Quote Originally Posted by Tolls View Post
    No I do understand.
    However those added methods that call X expecting X to do what they think X should do will fail...as you have said.
    ...
    Not what they think X does, but what you documented X to be! If you document it as "to be used only by M" then you are talking about useless private methods whose functionality should never have been split out.

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

    Default

    Quote Originally Posted by r035198x View Post
    Not what they think X does, but what you documented X to be!
    Then they can take me out back and shoot me...however I fail to see why this is not something that normal unit tests won't capture. Because at that point (ie when this new functionality fails its tests) one of the above mentioned cases comes into play. It's generally accepted that internal methods are very much open to refactoring.

    Quote Originally Posted by r035198x View Post
    If you document it as "to be used only by M" then you are talking about useless private methods whose functionality should never have been split out.
    Well, I don't document them like that, but they are all pretty much written with M in mind. And most of them are written in the full knowledge that they are unlikely to be useful outside of M. Why? Because large methods that do far too much are a pain in the arse to debug, refactor, or generally understand. So I disagree with this statement.

    Java Code:
    public void myMethod(SomeData someData) {
        doSomeInitialProcessing(someData);
        for (SubData subData : someData.getSubDataList()) {
            processSubData(subData);
        }
    }
    If doSomeInitialProcessing and processSubData are private methods written to do some of the work for this method and are unlikely to be used by something else are you implying that breaking them out is a waste of time?

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

    Default

    @Tolls:
    If that list is coming from something outside the class being tested then you should be able to mock the thing that is supplying the list.
    You shouldn't need to change your code like that to test it.
    That something outside is the provided "SomeOtherClass".
    This is the situation suggested by the OP.
    You are right that I could make a mocking class, but then I still had to switch classes for the test, by hand, or by the testingcode.
    How would I do the last thing without some if-statement or other intrusioncode? In my opinion that's the problem the OP suggested.
    SomeOtherClass is not injected like in Spring, it is a direct call, and the OP wants to supplement that. But I hope I'm overlooking some possibility.

    (Maybe I'm not making things better, but I still vote for r035198x .
    Only the last remark about split out functonality is not right i.m.h.o.: splitting out can be done just for clarity. )

    Remark: of course Spring-type injection, and calling an interface instead of a class is a cleaner solution.
    Last edited by Jodokus; 07-14-2011 at 07:10 PM. Reason: added remark
    No bug ever had to calculate its fitnessfunction.

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

    Default

    Quote Originally Posted by Jodokus View Post
    @Tolls:


    That something outside is the provided "SomeOtherClass".
    This is the situation suggested by the OP.
    You are right that I could make a mocking class, but then I still had to switch classes for the test, by hand, or by the testingcode.
    How would I do the last thing without some if-statement or other intrusioncode? In my opinion that's the problem the OP suggested.
    SomeOtherClass is not injected like in Spring, it is a direct call, and the OP wants to supplement that. But I hope I'm overlooking some possibility.
    That's the problem right there.
    The code should allow for injection, to open it up for testing. All it needs is a setter.

    Quote Originally Posted by Jodokus View Post
    (Maybe I'm not making things better, but I still vote for r035198x .
    Only the last remark about split out functonality is not right i.m.h.o.: splitting out can be done just for clarity. )
    No problem. If it was clear cut there wouldn't be a divide in the testing community.
    I take the view that the contract is at the class level. Below that (ie private methods) there is no defined contract so testing strikes me as overdoing it. Especially since, as I said, I break my work down into small methods...so do I test each little one simply because of the way I develop? To me that seems to be something that would drive your average developer to writing larger methods.

  10. #30
    batii is offline Member
    Join Date
    Jul 2011
    Posts
    1
    Rep Power
    0

    Default

    Reflection can be used to test private methods. The post Shyarmal's blog: TestNg example with jMock and reflection is an example. You may refer to the section under 'reflection usage break down'.

Page 2 of 2 FirstFirst 12

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
  •