What is more important, testability of code, or adherence to OOP principles?

Question

My teams evolution of TDD includes what appear to be departures from traditional oop.

1. Moving away from classes that are self sufficient We still encapsulate data where appropriate. But in order to mock any helper classes, we usually create some way to externally set them via constructor or mutator.

2. We don't use private methods, ever. In order to take advantage of our mocking framework (RhinoMocks) the methods can't be private. This has been the biggest one to "sell" to our traditional devs. And to some degree I see their point. I just value testing more.

What are your thoughts?

Answer 1

i am not familiar with rhinomocks, and in fact have never used or needed a mocking tool, so i may be way off base here, but:

• there should be no conflict between OO principles and TDD, because
• private methods do not need to be unit tested, only public ones

Answer 2

As a regular user of Intellisense, the requirement that all methods be public would drive me insane. I would adhere to OOP on that basis alone, personally.

Answer 3

Dependency Injection & Inversion of Control are fairly good ways to get the best of both worlds. Good design should not limit your ability to use the code in different ways (test), it should improve it.

We're re-writing a whole bunch of singletons to use DI/IOC right now so that we can test them (coming soon to a cable box near you).

Answer 4

You can also investigate dependency injection as a way to externalize some of the helper classes

Answer 5

If there is a framework which restricts me from using something like private methods, I drop it. Period. That's one of those fundamental things in most languages that's needed.

Answer 6

OOP is just one paradigm among many possible. It's not a goal in itself, it's a means to an end. You don't have to program object-oriented, not if other paradigms are better suited for you.

And countless clever people before you have remarked that unit testing tends to be a lot easier in function-oriented languages than object-oriented ones, simply because the natural unit for a test is a function. It's not a class (which may have private methods and all sorts of weird state), but a function.

Testability on the other hand, does have a value in itself. If your code isn't testable, you can't test it (obviously), and if you can't test it, how can you tell that it works? So if you have to choose one extreme or the other, I'd certainly choose testability.

But an obvious question is, do you really need to test every private method? These are not part of the public contract of a class, and may not be meaningful in isolation. The public methods are important to test because they have a specific purpose, they must fulfill this very specific contract, and leave the object in a consistent state and so on. They're inherently testable, in a way that a private method may not be. (Who cares what a private method does? It's not part of the class contract)

Perhaps a better solution would be to just refactor some of the otherwise private stuff out into separate classes. Perhaps the need for testing private methods isn't as big as you've been thinking.

On a different note, other mocking frameworks do allow you to mock private stuff too.

Edit: After thinking about it a bit further, I'd like to stress that just making private members public is probably a horrible idea. The reason we have private members in the first place is this: The class invariant must be maintained at all times. It must be impossible for external code to bring your class into an invalid state. That's not just OOP, it's also common sense. Private methods are simply to allow you finer granularity internally in the class, factoring some tasks out across multiple methods and such, but they generally do not preserve the class invariant. They do half the job, and then rely on some other private method being called afterwards to do the other half. And that's safe because they're not generally accessible. Only other class methods can call them, so as long as they preserve the invariant, all is well.

So while yes, you make the private methods testable by turning them public, you also introduce a source of bugs which can not be caught easily by unit tests. You make it possible to use the class "wrong". A well designed class always maintains its invariant, no matter how it's used by external code. Once you make everything public, that is no longer possible. External code can call internal helper functions which may not be used in that context, and which will throw the class into an invalid state.

And unit-tests can't really guarantee that this doesn't happen. So I'd say you risk introducing a much bigger source of errors than you might have expected.

Of course, given this above definition of private members (those that don't preserve the class invariant), it might be possible to safely turn a lot of other methods public, because they do preserve the invariant, and so there's no need to hide them from external code. So that might make lessen your problem, by giving you fewer private methods, but without allowing external code to break your class, as would be possible if everything was public.

Answer 7

I use Rhino Mocks and I use lots of private methods. I usually write my classes to depend on interfaces rather than other classes, because that makes mocking easier.

Answer 8

Regarding the classes scope, you could use internals to simplify the framework (for the end-users) and specify in the framework project AssemblyInfo.cs

[assembly: InternalsVisibleTo("MyAssembly.Tests")]

Answer 9

Good OO design is more than encapsulation, more than having private methods.

One of the major design smells is coupling between different parts of the system. Before you were injecting helper classes into your objects to test them, how were your objects getting access to the helpers?

My guess is that by switching to dependency injection you've lowered the coupling in your system.

There's also the Open/Closed principle. By injecting helper classes you allow polymorphic substitution of behavior.

And if there's some concern about having non-private methods visible on a class, use the class through its interface, which is a good idea anyway, right?

Answer 10

Maintainability is more important.

Don't miss the point that both, unit testing and OOP have that goal in common.

Answer 11

I am not familiar with any conflict between them all. High cohesion and low coupling are the core of OO and that happens to be the core of testing as well.

Answer 12

OOP is a tool, not a goal

Answer 13

Why not just use a macro instead of the private keyword. WHen you compile with "testmode" on, those methods are public. Otherwise they are private. With a macro, you'll still get compiler warnings when you use your private methods publicly, once you compile not in testing mode. It is interesting to note that having your private methods fail their unit tests does not imply a bug in your program, though it is likely equivalent to having a function, "CauseBSOD" which is never called. It's a heavily broken function (assuming causing BSOD's is not intended), but it isn't a bug as far as users are concerned.

Answer 14

What you are experiencing is that tests exert forces on the design. That's actually the reason why TDD is mainly a design strategy - writing the tests forces a better decoupled design, if you pay attention and know how to read the signs.

Injecting "helper objects" into classes is in fact a good thing. You shouldn't think of them as helper objects, though. They are regular objects, hopefully at a different level of abstraction. They are basically Strategies, that configure how the details of the higher level algorithms get filled in. (I typically inject them using a constructor, and also provide another constructor that automatically uses the default production implementation, if there is one.) Beware though - mocking can also be overdone, in my experience. Take a look at http://martinfowler.com/articles/mocksArentStubs.html for some interesting thoughts on the topic.

Regarding private methods, I don't fully understand what this has to do with your mocking framework - typically, you should mock interfaces, which only have public methods, anyway, which are part of the public contract.

Anyway, complex private methods are a code smell, in my opinion - it's a sign that the class probably is taking on too much responsibility, violating the Single Responsibility Principle. Think about on what kind of class it would actually not be a violation of encapsulation to make it public. Moving the method to that class (possibly creating it on the way) is likely going to improve your design in terms of coupling and cohesion.

Answer 15

Why can't you use friend classes that are only test classes? Alternatively your test classes derive from the parent classes that have private members.

Making everything public to cater to bad testing tools is a mistake in my opinion. As others have said - this shouldn't have to be a choice. Design good software. Test well and use good tools. If you have to break well-known best practices for some test tool then it is time to rethink your test tool...