OO Design for Unit Tests

Hmmm. I'm working a contract right now, so there hasn't been much progress on the requirements management system.

I'm currently fixing problems with some existing code. At the same time, I was looking at writing some automated C-unit style unit tests for my fixes. The only problem is that the scaffolding that I would have to erect around the code to even test a single function.

It brought a lesson home to me. In a lot of object oriented code, you see people with long chains of getters until they obtain what they are looking for and call a final function on that. eg:

  transaction->getConnection()->getStatus()

The only problem is that in order to test this code in isolation, you not only have to create a stub transaction, but you have to create a stub connection too! If it looked like this instead:

  transaction->getConnectionStatus()

We would only have to stub out transaction!

I have always read in articles and books that if you "have a" member that is itself a class, instead of simply exposing it in a getter, you are better to expose the individual member functions of the enclosed member object. I guess I now understand why.

The only question is how do you maintain the isolation of interfaces, and avoid writing a lot of code?