Confused on TDD wrappers/adapters

Question

Hi, I'm new to the TDD scene and trying to isolate my tests is having me go around in circles.

I have an app I am trying to write that uses OpenXML so it has a mass of objects that it depends on to work from an external framework. I thought it would be a good idea to have wrappers around these objects so I was isolated from them in case of changes etc. My problem is that to represent something like a Cell, I am passing in a real Cell into my wrapper (so it has something to wrap) in the constructor.

To test this wrapper, I have to pass in a real Cell from the OpenXML framework. Ok that's do-able but I also wanted to pass in a SharedStringTablePart to the constructor so it could store the string value (if it was a sharedstring) for easy retrieval. SharedStringTablePart has a protected constructor so you can't just create one on the fly in a test to test with.

Sooo, I create a wrapper for that too but how do I test this new wrapper? I can't pass in a SharedStringTablePart via dependency injection as I can't construct one.

I have to talk to the 3rd party interface at some point in my app architecture don't I and test that layer?

Do I just create wrappers and not bother with the TDD part of them and just assume they will work if I pass through the same requests and respond with the same responses the actual wrapped object would expect/do?

Not that it makes any difference at this level but I am using c#

thanks Nev

Answer 1

That's the problem with integration code, it doesn't fit well unit testing.

Above doesn't mean you are to drop unit testing all around, just not for integration code.

The way you are designing those wrappers is tightly coupling them to the external objects. imho that's just shifting the problem / moving the code around.

Don't receive the external objects in the constructor and do the mapping in there. Pull that out of all those objects, instead handle it in code which only responsibility is to map the representation from the external system to the internal representation.

That's the way you'd keep the dependency from the rest of your code. I'd have some code that's responsible from communicating with the third party library, that code doesn't expose any of the types you want to keep from the rest of the system. Also doesn't hide it inside other objects, it either maps them directly or calls code that maps them.