in reply to "Accessors break encapsulation"?

Yes, the general rule really only applies to public accessors and mutators. From the outside, you should be telling an object what to do and then let the object change its own state.

should a test suite test only the published API, or should it also test private methods?

A test suite should aim for the highest practical code coverage. For every public method called, there are probably some underlieing private methods called. The test suite may then end up having complete coverage of the object without actually calling private methods.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Replies are listed 'Best First'.
Re^2: "Accessors break encapsulation"
by etm117 (Pilgrim) on Jul 19, 2005 at 15:35 UTC
    If practical (dependent on time constraints, complexity of the project, etc.) I like to test internal/private methods also. As stated in the OP, it allows me to feel more safe when refactoring my internal stuff.

    If you test just the public methods, that one test failing won't point to which internal/private method is broken by your refactoring or adding features. Testing the internal/private methods will point out what is broke at a level of granularity lower than just testing the public interface.

[reply]
      I do see the debugging value that you're talking about, but the danger in extensive testing of private methods is that it makes the test cases fragile.

      The important thing when you are refactoring is that all of the public methods continue to adhere to the interface; if you have to update your test suite every time you make a change you might be reluctant to make internal improvements.

[reply]
        I will most definitely agree on that point.

        I am still relatively new to testing, so I don't think I have gotten to the point that I am bothered by the tediousness of updating the test suite each time I make an internal refactor change to the code.

        /me now ponders whether the extra test cases on private methods are beneficial enough that they will be worth the extra effort in the long run, hmmm...

[reply]
        If your classes do substantial calculations, it's useful to test the private methods that do the sub-calculations.

        Otherwise, you'll probably end up doing more work to manage all the code coverage cases. That is, you'll need to do the same code coverage, but you'll have to reason out how to get to each submethod, and ensure you pass it the right parameters to ensure all of it's children get called.

        I'd just as soon call all the children directly, with valid, invalid, likely, and not so likely datasets, and ensure that all cases are handled correctly. If I know the sub-methods do their jobs, then testing the API becomes more of an excercise in confirming the behaviour of the API against the final set of business requirements, versus a frantic search for coding errors.

        If you only test the API, you also run the risk of your subroutines containing hidden flaws that cancel each other out. If you try to re-use or refactor such flawed code, you'll be in for nasty surprises later on...

        But then again, testing is a lot of work in general, and if you refactor the internal methods, updating the test suite each time is a real pain.
        --
        AC

[reply]

In Section Meditations