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:
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:
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?
Post a Comment