TDD — What about internal methods?

Over the past few months, I’ve taken part in a few chats about whether or not internal methods should be tested. One of the basic premises of TDD is that you should use it to explore, design, and implement the public interface of your classes. If you are using it to test methods that are less than public, you are probably testing implementation and not interface, which leads to very fragile tests.

For the longest time I didn’t believe that. I truly believed that internal methods were just another “public”-like interface, to a smaller audience. And I just spent 30 minutes writing this blog entry explaining my reasoning. And as I went through my arguments, I started thinking. And then I erased what I had written.

So, this is my new post:

A few weeks ago I posted an entry called Extreme Refactoring. One of the goals of what I did was to eliminate all private methods, just to see where that took the design. I liked where it went, and it has changed how I think about new code that I write.

Maybe, must maybe, we can do the same kind of thing with internal methods. Private methods are an indication that a class is doing too much. It is possible to move that logic out of the private methods into public methods of other classes. And maybe it is possible that a class that has both public and internal methods is doing too much as well. Maybe that’s a hint that that class is doing too much.

At this point I don’t know. I really meant this posting to be an explanation of why writing internal methods through TDD made sense, since they weren’t really anything other than scoped publics. But now I’m starting to wonder. I just don’t know. I’m going to have to try to write code cognizant of this and see where it takes me. Maybe in well defined and factored classes, you have either private, protected, and public methods. I haven’t decided if internal classes are OK or not — I’ll have to try it and find out.

The problem I have seen is that in large applications, there are services that classes offer to each other, inside the bounds of the application, that classes outside the application should not be able to consume. Internal methods go part of the way towards solving this, but even they break down when the application spans multiple assemblies. I want to find a way to address this issue, but still create safe, security-conscious code.

Sorry for the ramble, but this was really an exploration and journey for me to get to this point. I look forward to trying this theory out.



Now playing: Liquid Tension Experiment – Liquid Tension Experiment 2 – Liquid Dreams

10 thoughts to “TDD — What about internal methods?”

  1. I think libraries are a different beast. Sometimes I think of a library’s interface as a facade of something else. This facade should make it easy for me to use the library. But this facade doesn’t have to be more than a package in front of the ‘real’ code.

    When I see the number of private methods grow, I always wonder if this is a smell or not. I usually have a lot of small, intention revealing methods. Their purpose is to simplify structure and, hopefully, better explain my intentions. They are not part of the public interface, and sometimes I can’t see that they belong somewhere else.

    Once in a while I will extract them to their own class, just to see what it will look like. I usually move them back if the code didn’t improve.

  2. Thomas,

    Did you read my Extreme Refactoring post? I’ve really tried to turn up the knobs on moving private methods to other classes, and I like what its done to my code.

    I agree with your contention about libraries being different. On Enterprise Library, our problem was that we had 38 separate assemblies that made up entlib, and there were times when there were services that one assembly had to offer to another. All we could do at that point was to annotate the method as being for internal use only.


  3. Widhbey has a new attribute InternalsVisibleToAttribute which lets you specify an assembly name that can "see" the internal types.

  4. Yeah, I’ve heard of that, but I haven’t had a chance to try it out yet. It sounds like it might exactly fit the bill for what I need. But doesn’t it require you to sign your assemblies to get it to work?

    What I really want to do is to draw a circle in the sand and say that everything inside that circle has special privileges, but only slightly special. I want them to access internal stuff, but nothing private. This would be particulary cool for assemblies of test fixtures.

    I do need to play with this feature some time.

    Thanks for reminding me about it!


  5. i need to find out the internal methods of agiven java file.



    public void display();

    private String getEmp();

    public void display()


    this.get method();



    i need to find out the methods and internal methods

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.