Should I avoid private methods if I perform TDD?

Question

I'm just now learning TDD. It's my understanding that private methods are untestable and shouldn't be worried about because the public API will provide enough information for verifying an object's integrity.

I've understood OOP for a while. It's my understanding that private methods make objects more encapsulated, thus more resistant to change and errors. Thus, they should be used by default and only those methods that matter to clients should be made public.

Well, it's possible for me to make an object that has only private methods and interacts with other objects by listening to their events. This would be very encapsulated, but completely untestable.

Also, it's considered bad practice to add methods for the sake of testing.

Does this mean TDD is at odds with encapsulation? What is the appropriate balance? I'm inclined to make most or all of my methods public now...

Answer 1

Prefer testing to the interface over testing on the implementation.

It's my understanding that private methods are untestable

This depends on your development environment, see below.

[private methods] shouldn't be worried about because the public API will provide enough information for verifying an object's integrity.

That's right, TDD focuses on testing the interface.

Private methods are an implementation detail that could change during any re-factor cycle. It should be possible to re-factor without changing the interface or the black-box behaviour. In fact, that is part of the benefit of TDD, the ease with which you can generate the confidence that changes internal to a class will not affect users of that class.

Well, it's possible for me to make an object that has only private methods and interacts with other objects by listening to their events. This would be very encapsulated, but completely untestable.

Even if the class has no public methods, it's event handlers are it's public interface, and it its against that public interface that you can test.

Since the events are the interface then it is the events that you will need to generate to test that object.

Look into using mock objects as the glue for your test system. It should be possible to create a simple mock object that generates an event and picks up the resultant change of state (possible by another receiver mock object).

Also, it's considered bad practice to add methods for the sake of testing.

Absolutely, you should be very wary of exposing internal state.

Does this mean TDD is at odds with encapsulation? What is the appropriate balance?

Absolutely not.

TDD shouldn't change the implementation of your classes other than to perhaps simplify them (by applying YAGNI from an earlier point).

Best practice with TDD is identical to best practice without TDD, you just find out why sooner, because you are using the interface as you are developing it.

I'm inclined to make most or all of my methods public now...

This would be rather throwing the baby out with the bath water.

You shouldn't need to make all methods public so that you can develop in a TDD way. See my notes below to see if your private methods really are untestable.

A more detailed look at testing private methods

If you absolutely must unit test some private behaviour of a class, depending on the language/environment, you may have three options:

1. Put the tests in the class you want to test.
2. Put the tests in another class/source file & expose the private methods you want to test as public methods.
3. Use a testing environment that allows you to keep test and production code separate, yet still allow testing code access to private methods of the production code.

Obviously the 3rd option is by far the best.

1) Put the tests in the class you want to test (not ideal)

Storing test cases in the same class/source file as the production code under test is the simplest option. But without a lot of pre-processor directives or annotations you will end up with your test code bloating your production code unnecessarily, and depending on how you have structured your code, you may end up accidentally exposing internal implementation to users of that code.

2) Expose the private methods you want to test as public or protected methods (really not a good idea)

As suggested this is very poor practice, destroys encapsulation and will expose internal implementation to users of the code.

3) Use a better testing environment (best option, if it is available)

In the Eclipse world, 3. can be achieved by using fragments. In the C# world, we might use partial classes. Other languages/environments often have similar functionality, you just need to find it.

Blindly assuming 1. or 2. are the only options would be likely to result in production software bloated with test code or nasty class interfaces that wash their dirty linen in public. *8')

• All in all - it is much better not to test against private implementation though.

Answer 2

Of course you can have private methods, and of course you can test them.

Either there is some way to get the private method to run, in which case you can test it that way, or there is no way to get the private to run, in which case: why the heck are you trying to test it, just delete the damn thing!

In your example:

Well, it's possible for me to make an object that has only private methods and interacts with other objects by listening to their events. This would be very encapsulated, but completely untestable.

Why would that be untestable? If the method is invoked in reaction to an event, just have the test feed the object an appropriate event.

It's not about having no private methods, it's about not breaking encapsulation. You can have private methods but you should test them through the public API. If the public API is based on events, then use events.

For the more common case of private helper methods, they can be tested through the public methods that call them. In particular, since you are only allowed to write code to get a failing test to pass and your tests are testing the public API, all new code you write is usually going to be public. Private methods only appear as a result of an Extract Method Refactoring, when they are pulled out of an already existing public method. But in that case, the original test which tests the public method still covers the private method as well, since the public method calls the private method.

So, usually private methods only appear when they are extracted from already tested public methods and are thus already tested as well.

Answer 3

When you create a new class in your code, you do it to answer some requirements. The requirements say what the code must do, not how. This makes it easy to understand why most testing happens at public methods level.

Through tests, we verify that the code does what it is expected to do, throws appropriate exceptions when expected, etc. We don't really care how the code is implemented by the developer. While we don't care about implementation, i.e. how the code does what it does, it makes sense to avoid testing private methods.

As for testing classes which don't have any public methods and interact with the outside world only through events, you can test this too by sending, through tests, the events and listening to the response. For example if a class must save a log file each time it receives an event, the unit test will send the event and verify that the log file is written.

Last but not least, in some cases it is perfectly valid to test private methods. That's why for example in .NET, you can test not only public, but also private classes, even if the solution is not as straightforward as for public methods.

Answer 4

It's my understanding that private methods are untestable

I disagree with that statement, or I would say you don't test private methods directly. A public method may call different private methods. Maybe the author wanted to have "small" methods and extracted some of the code into a cleverly named private method.

Regardless of how the public method is written, your test code should cover all paths. If you discover after your tests that one of the branch statement (if/switch) in one private method has never been covered in your tests, then you have a problem. Either you missed a case and the implementation is correct OR the implementation is wrong, and that branch should never have existed in fact.

That is why I use Cobertura and NCover a lot, to make sure that my public method test also covers private methods. Feel free to write good OO objects with private methods and don't let TDD/Testing go in your way in such matter.

Answer 5

Your example is still perfectly testable as long as you use Dependency Injection to provide the instances that your CUT interacts with. Then you can use a mock, generate the events of interest, and then observe whether or not the CUT takes the correct actions on its dependencies.

On the other hand, if you have language with good event support you may take a slightly different path. I don't like when objects subscribe to events themselves, instead have the factory that creates the object wire up events to the public methods of the object. It's easier to test, and makes it externally visible what kinds of events the CUT needs to be tested for.

Answer 6

You should not need to abandon using private methods. It's perfectly reasonable to use them, but from a testing perspective they are harder to test directly without either breaking encapsulation or adding test-specific code to your classes. The trick is to minimize the stuff that you know is going to make your gut squirm because you feel like you've dirtied your code.

These are the things that I keep in mind to try and achieve a workable balance.

1. Minimize the number of private methods and properties that you use. Most of the stuff you need your class to do tends to need to be exposed publicly anyway, so have a think about whether you really do need to make that clever method private.
2. Minimize the amount of code in your private methods - you really should be doing this anyway - and test indirectly where you can via the behavior of other methods. You never expect to get 100% test coverage, and perhaps you will need to hand check a few values via the debugger. Using private methods to throw Exceptions can easily be tested indirectly. Private properties may need to be tested manually, or via another method.
3. If indirect or manual checking doesn't sit well with you, add a protected event and access via an Interface to expose some of the private stuff. This effectively "bends" the rules of encapsulation, but avoids the need to actually ship code that executes your tests. The drawback is that this can result in a little additional internal code to make sure that the event will be fired when needed.
4. If you feel that a public method isn't "secure" enough, see if there are ways you can implement some sort of validation process in your methods to limit how they are used. Chances are that while you are thinking this through either think of a better way to implement your methods, or you'll see another class beginning to take shape.
5. If you have a lot of private methods doing "stuff" for your public methods, there may be a new class waiting to be extracted. You can test this directly as a separate class, but implement as a composite privately within the class that uses it.

Think laterally. Keep your classes small and your methods smaller, and use lots of composition. It sounds like more work, but in the end you'll end up with more individually testable items, your tests will be simpler, you'll have more options for using simple mocks in place of real, large and complex objects, hopefully well-factored and loosely coupled code, and more importantly you'll give your self more options. Keeping things small tends to save you time in the end, because you reduce the number of things you need to individually check on each class, and you tend to naturally reduce the code spaghetti that can sometimes happen when a class gets large and has lots of interdependent code behavior internally.

Answer 7

Well, it's possible for me to make an object that has only private methods and interacts with other objects by listening to their events. This would be very encapsulated, but completely untestable.

How does this object react to those events? Presumably, it must invoke methods on other objects. You can test it by checking whether those methods get called. Have it call a mock object and then you can easily assert that it does what you expect.

The issue is that we only want to test the object's interaction with other objects. We don't care what's going on inside an object. So no, you shouldn't have any more public methods then before.

Answer 8

I've struggled with this same issue as well. Really, the way to get around it is this: How do you expect the rest of your program to interface with that class? Test your class accordingly. This will force you to design your class based on how the rest of the program interfaces with it and will, in fact, encourage encapsulation and good design of your class.

Answer 9

Instead of private use default modifier. Then you can test those methods individually, not just coupled with public methods. This requires that your tests have the same package structure as your main code.

Answer 10

A few private methods usually aren't an issue. You just test them through the public API as if the code were inlined into your public methods. An excess of private methods may be a sign of poor cohesion. Your class should have one cohesive responsibility, and often people make methods private to give the appearance of cohesiveness where none really exists.

For example, you might have an event handler that makes a lot of database calls in response to those events. Since it's obviously bad practice to instantiate an event handler to make database calls, the temptation is to make all the database-related calls private methods, when they should really be pulled out into a separate class.

Answer 11

Does this mean TDD is at odds with encapsulation? What is the appropriate balance? I'm inclined to make most or all of my methods public now.

TDD is not at odds with encapsulation. Take the simplest example of a getter method or property, depending on your language of choice. Let's say that I have a Customer object and I want it to have an Id field. The first test I'm going to write is one that says something like "customer_id_initializes_to_zero". I define the getter to throw a not implemented exception and watch the test fail. Then, the simplest thing I can do to make that test pass is have the getter return zero.

From there, I go onto other tests, presumably ones that involve the customer ID being an actual, functional field. At some point, I probably have to create a private field that the customer class uses to keep track of what should be returned by the getter. How exactly do I keep track of this? Is it a simple backing int? Do I keep track of a string and then convert it to int? Do I keep track of 20 ints and average them? The outside world doesn't care - and your TDD tests don't care. That is an encapsulated detail.

I think this is not always immediately obvious when starting TDD -- you're not testing what methods do internally - you're testing less granular concerns of the class. So, you're not looking to test that method DoSomethingToFoo() instantiates a Bar, calls a method on it, adds two to one of its properties, etc. You're testing that after you mutate the state of your object, some state accessor has changed (or not). That's the general pattern of your tests: "when I do X to my class under test, I can subsequently observe Y". How it gets to Y is none of the tests' concern, and this is what is encapsulated and this is why TDD is not at odds with encapsulation.

Answer 12

Avoid using? No.
Avoid starting with? Yes.

I notice you didn't ask about whether it's ok to have abstract classes with TDD; if you understand how abstract classes emerge during TDD, the same principle applies to private methods as well.

You can't directly test methods in abstract classes just like you can't directly test private methods, but that's why you don't start out with abstract classes and private methods; you start with concrete classes and public APIs, and then you refactor common functionality as you go.

Answer 13

I'm curious how in the 9 years this question has been out there, nobody has pointed out that if you are doing TDD (Test-driven development), you should not be writing any method (public or private) unless it is to pass a failing test.

As such, it's an irrelevant question: tests force you to write public methods, which should in turn be refactored. That refactoring may involve extracting logic to private methods--but that only works if the tests still pass. That is, the "extract a method" involves creating a call to the new private method from a method that is already causing one or more tests to pass. Moreover, refactoring involves NOT adding logic, and TDD forbids adding logic if it is not being added to pass a failing test. So, if you're actually practicing TDD, all methods--public, private, protected, or whatever--will automatically be covered by the tests.

Answer 14

Your class has requirements. Roughly speaking, your class should have public methods which correspond to the requirements, and no others.

And your class needs code to implement the requirements. Depending on the requirements, it might need a lot of code. And for various reasons your methods shouldn’t be too large.

If you insist on no private methods, then all the code must be put into the public methods which is obviously rubbish. So you add exactly as many private methods as you need to have a class with good code. Testability is not everything. Actually, testability is nothing if you violate good coding principles and end up with code that is always too buggy to pass your tests.

Methods are made private to prevent every old bit of code to call them. That doesn’t mean you don’t want to test them. For example on MacOS / iOS you just mark a method as @testable and it can be called like a public method when you are building unit tests or other tests, but not when you are building an application.